diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/datatype.sgml | 14 | ||||
| -rw-r--r-- | doc/src/sgml/func.sgml | 48 |
2 files changed, 42 insertions, 20 deletions
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 9dfecbbbc3b..b62ee05a4c2 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -803,6 +803,20 @@ ALTER SEQUENCE <replaceable class="parameter">tablename</replaceable>_<replaceab </para> <note> + <para> + Because <type>smallserial</type>, <type>serial</type> and + <type>bigserial</type> are implemented usings sequences, there may + be "holes" or gaps in the sequence of values which appears in the + column, even if no rows are ever deleted. This is a value allocated + from the sequence is still "used up" even if a row containing that + value is never successfully inserted into the table column. This + may happen, for example, if the inserting transaction rolls back. + See <literal>nextval()</literal> in <xref linkend="functions-sequence"> + for details. + </para> + </note> + + <note> <para> Prior to <productname>PostgreSQL</productname> 7.3, <type>serial</type> implied <literal>UNIQUE</literal>. This is no longer automatic. If diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 4eb91311e6b..fcad177b7d2 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -9741,6 +9741,27 @@ nextval('foo'::text) <lineannotation><literal>foo</literal> is looked up at execute <function>nextval</function> concurrently, each will safely receive a distinct sequence value. </para> + + <para> + If a sequence object has been created with default parameters, + successive <function>nextval</function> calls will return successive + values beginning with 1. Other behaviors can be obtained by using + special parameters in the <xref linkend="sql-createsequence"> command; + see its command reference page for more information. + </para> + + <important> + <para> + To avoid blocking concurrent transactions that obtain numbers from the + same sequence, a <function>nextval</function> operation is never + rolled back; that is, once a value has been fetched it is considered + used, even if the transaction that did the + <function>nextval</function> later aborts. This means that aborted + transactions might leave unused <quote>holes</quote> in the sequence + of assigned values. + </para> + </important> + </listitem> </varlistentry> @@ -9804,31 +9825,18 @@ SELECT setval('foo', 42, false); <lineannotation>Next <function>nextval</> wi The result returned by <function>setval</function> is just the value of its second argument. </para> + <important> + <para> + Because sequences are non-transactional, changes made by + <function>setval</function> are not undone if the transaction rolls + back. + </para> + </important> </listitem> </varlistentry> </variablelist> </para> - <para> - If a sequence object has been created with default parameters, - successive <function>nextval</function> calls will return successive values - beginning with 1. Other behaviors can be obtained by using - special parameters in the <xref linkend="sql-createsequence"> command; - see its command reference page for more information. - </para> - - <important> - <para> - To avoid blocking concurrent transactions that obtain numbers from the - same sequence, a <function>nextval</function> operation is never rolled back; - that is, once a value has been fetched it is considered used, even if the - transaction that did the <function>nextval</function> later aborts. This means - that aborted transactions might leave unused <quote>holes</quote> in the - sequence of assigned values. <function>setval</function> operations are never - rolled back, either. - </para> - </important> - </sect1> |