Thread: Sequences : getting back the nextval() result on an insert

On Thu, 11 Jun 1998, Wim Ceulemans wrote:

> Hi
>
> I am new to this list, but I've carefully searched the archives before posting this question.
>
> I am using JDBC to access postgreSQL 6.3.
>
> If one inserts records using a sequence to generate an auto-increment primary key, then you can get back the result
byusing "select currval('seq')". There is always a time between the insert and the select to retrieve the newly created
primarykey. Wh 

at I do in my application is insert a record and display it in a java swing JTable (including the primary key).
>
> How can I be certain that the primary key I retrieve with select currval('seq') is the one just inserted? Because in
heavilyloaded multi-user systems someone else can insert a record in the same table between my insert and my select. 
>

Actually, as each user spawns a new copy of the backend u can be sure that
currval() gives correct answer as it uses it's backend information. I.e
nextval() and curval() called sequently from the same process/application
will refer to their backend.

If u look at the create secuence schema dump (pg_dump -s XXX) u will see
the CACHE parameter which AFAIK referes to the pool of sequence numbers
alocated per backend.

Hope this helps...

    Marin


          -= Why do we need gates in a world without fences? =-

On Thu, 11 Jun 1998, Wim Ceulemans wrote:

> Hi
>
> I am new to this list, but I've carefully searched the archives before posting this question.
>
> I am using JDBC to access postgreSQL 6.3.
>
> If one inserts records using a sequence to generate an auto-increment primary key, then you can get back the result
byusing "select currval('seq')". There is always a time between the insert and the select to retrieve the newly created
primarykey. Wh 

at I do in my application is insert a record and display it in a java swing JTable (including the primary key).
>
> How can I be certain that the primary key I retrieve with select currval('seq') is the one just inserted? Because in
heavilyloaded multi-user systems someone else can insert a record in the same table between my insert and my select. 
>

Actually, as each user spawns a new copy of the backend u can be sure that
currval() gives correct answer as it uses it's backend information. I.e
nextval() and curval() called sequently from the same process/application
will refer to their backend.

If u look at the create secuence schema dump (pg_dump -s XXX) u will see
the CACHE parameter which AFAIK referes to the pool of sequence numbers
alocated per backend.

Hope this helps...

    Marin


          -= Why do we need gates in a world without fences? =-

On Thu, 11 Jun 1998, Wim Ceulemans wrote:

> Hi
>
> I am new to this list, but I've carefully searched the archives before posting this question.
>
> I am using JDBC to access postgreSQL 6.3.
>
> If one inserts records using a sequence to generate an auto-increment primary key, then you can get back the result
byusing "select currval('seq')". There is always a time between the insert and the select to retrieve the newly created
primarykey. Wh 

at I do in my application is insert a record and display it in a java swing JTable (including the primary key).
>
> How can I be certain that the primary key I retrieve with select currval('seq') is the one just inserted? Because in
heavilyloaded multi-user systems someone else can insert a record in the same table between my insert and my select. 
>

Actually, as each user spawns a new copy of the backend u can be sure that
currval() gives correct answer as it uses it's backend information. I.e
nextval() and curval() called sequently from the same process/application
will refer to their backend.

If u look at the create secuence schema dump (pg_dump -s XXX) u will see
the CACHE parameter which AFAIK referes to the pool of sequence numbers
alocated per backend.

Hope this helps...

    Marin


          -= Why do we need gates in a world without fences? =-