|PostgreSQL 8.1.23 Documentation|
|Prev||Fast Backward||Chapter 9. Functions and Operators||Fast Forward||Next|
This section describes PostgreSQL's functions for operating on sequence objects. Sequence objects (also called sequence generators or just sequences) are special single-row tables created with CREATE SEQUENCE. A sequence object is usually used to generate unique identifiers for rows of a table. The sequence functions, listed in Table 9-34, provide simple, multiuser-safe methods for obtaining successive sequence values from sequence objects.
Table 9-34. Sequence Functions
||bigint||Advance sequence and return new value|
||bigint||Return value most recently obtained with
||bigint||Return value most recently obtained with
||bigint||Set sequence's current value|
||bigint||Set sequence's current value and is_called flag|
The sequence to be operated on by a sequence-function call is specified by a regclass argument, which is just the OID of the sequence in the pg_class system catalog. You do not have to look up the OID by hand, however, since the regclass data type's input converter will do the work for you. Just write the sequence name enclosed in single quotes, so that it looks like a literal constant. To achieve some compatibility with the handling of ordinary SQL names, the string will be converted to lowercase unless it contains double quotes around the sequence name. Thus
nextval('foo') operates on sequence foo nextval('FOO') operates on sequence foo nextval('"Foo"') operates on sequence Foo
The sequence name can be schema-qualified if necessary:
nextval('myschema.foo') operates on myschema.foo nextval('"myschema".foo') same as above nextval('foo') searches search path for foo
See Section 8.12 for more information about regclass.
Note: Before PostgreSQL 8.1, the arguments of the sequence functions were of type text, not regclass, and the above-described conversion from a text string to an OID value would happen at run time during each call. For backwards compatibility, this facility still exists, but internally it is now handled as an implicit coercion from text to regclass before the function is invoked.
When you write the argument of a sequence function as an unadorned literal string, it becomes a constant of type regclass. Since this is really just an OID, it will track the originally identified sequence despite later renaming, schema reassignment, etc. This "early binding" behavior is usually desirable for sequence references in column defaults and views. But sometimes you will want "late binding" where the sequence reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass:nextval('foo'::text) foo is looked up at runtime
Note that late binding was the only behavior supported in PostgreSQL releases before 8.1, so you may need to do this to preserve the semantics of old applications.
Of course, the argument of a sequence function can be an expression as well as a constant. If it is a text expression then the implicit coercion will result in a run-time lookup.
The available sequence functions are:
Advance the sequence object to its next value and return
that value. This is done atomically: even if multiple
concurrently, each will safely receive a distinct sequence
Return the value most recently obtained by
nextval for this sequence in the current
session. (An error is reported if
nextval has never been called for this
sequence in this session.) Notice that because this is
returning a session-local value, it gives a predictable
answer whether or not other sessions have executed
nextval since the current
Return the value most recently returned by
nextval in the current session. This
function is identical to
currval, except that instead of taking
the sequence name as an argument it fetches the value of
the last sequence that
nextval was used on in the current
session. It is an error to call
nextval has not yet been called in the
Reset the sequence object's counter value. The
two-parameter form sets the sequence's last_value field to the specified value and
sets its is_called field to
true, meaning that the next
nextval will advance the
sequence before returning a value. In the three-parameter
form, is_called may be set either
true or false. If it's set to false, the next
nextval will return exactly the specified
value, and sequence advancement commences with the
SELECT setval('foo', 42); Next
nextvalwill return 43 SELECT setval('foo', 42, true); Same as above SELECT setval('foo', 42, false); Next
nextvalwill return 42
The result returned by
setval is just the value of its second
If a sequence object has been created with default parameters,
nextval calls on it will return
successive values beginning with 1. Other behaviors can be
obtained by using special parameters in the CREATE SEQUENCE command; see its
command reference page for more information.
Important: To avoid blocking of concurrent transactions that obtain numbers from the same sequence, a
nextvaloperation is never rolled back; that is, once a value has been fetched it is considered used, even if the transaction that did the
nextvallater aborts. This means that aborted transactions may leave unused "holes" in the sequence of assigned values.
setvaloperations are never rolled back, either.
If you would like to use currval() without using nextval() at all, consider using the following statement instead:
SELECT last_value FROM schema.sequence
It's gonna save you some frustration.
As Francis write, We can define even such function
CREATE OR REPLACE FUNCTION "public"."globalcurrval" (schema_sequence varchar) RETURNS integer AS
EXECUTE 'SELECT last_value FROM' || schema_sequence INTO m_result;
LANGUAGE 'plpgsql' VOLATILE RETURNS NULL ON NULL INPUT SECURITY INVOKER;
| globalcurrval |
| 8627 |
1 row in set
Francis' SELECT statement works fine if you can ensure that no INSERTs happen using the sequence between your INSERT and the SELECT last_value.
Unfortunately, it does not work in a threaded or multi-process environment where others may be inserting into the table that uses that sequence.
In a multi-threaded environment, the following will work much better, and save you much frustration: