Re: Re: INSERT ... RETURNING as Oracle

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Martin A(dot) Marques" <martin(at)math(dot)unl(dot)edu(dot)ar>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Re: INSERT ... RETURNING as Oracle
Date: 2001-03-05 15:57:38
Message-ID: 19821.983807858@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Martin A. Marques" <martin(at)math(dot)unl(dot)edu(dot)ar> writes:
> If I have a client INSERT a value in a table (all happens inside a BEGIN
> WORK ---- COMMIT WORK), which has a SERIAL column, and I want to
> reference that serial value on another INT column which is a foreign key
> of that SERIAL. Using currval() function will give me exact value as the
> FAQs say, and why? Is it the transaction that makes this work this way?

No, it has nothing to do with transaction boundaries; it'd work the same
even if you did the currval() in a later transaction. The reason it
works is that each backend remembers the last nextval() result it got
for each sequence it's nextval'd in the current session. currval() just
pulls that value out of the local table without ever touching the shared
sequence object. Simple, eh?

Of course, you can still get burnt if you have triggers and such that
do nextval()s on the same sequence your main-line code is touching.
Then one of them might do a nextval() "behind your back", so to speak.
But that sort of foulup is a straight programming error that doesn't
have anything to do with parallel behavior of multiple clients.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Peter T Mount 2001-03-05 15:58:23 Re: [INTERFACES] 'Unknown Result Type' - JDBC Driver
Previous Message Hernan Gonzalez 2001-03-05 15:48:29 Re: Re: SERIAL values