From: | "Brett W(dot) McCoy" <bmccoy(at)chapelperilous(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Catalin CIOCOIU <catalin(dot)ciocoiu(at)inpg(dot)fr>, "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: Last ID |
Date: | 2001-03-02 18:23:45 |
Message-ID: | Pine.LNX.4.30.0103021315290.22539-100000@chapelperilous.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
On Fri, 2 Mar 2001, Tom Lane wrote:
> Quite a few people don't seem to understand how currval() and nextval()
> work.
>
> 1. nextval() advances the sequence object, generating a new value that
> will not be the same as any other nextval() call returns, in either
> this backend or any other one.
>
> 2. currval() gives the last value generated by a nextval() *IN THIS
> BACKEND*. It is undefined until the current backend has done at
> least one nextval() on the sequence object.
>
> There is no "multiuser risk" from either one: in particular, currval()
> will give you the value you last generated, regardless of what other
> backends may be doing.
How ironic... I got into an argument not too long ago with someone on the
Perl-DBI list who insisted that currval could not be reliably used in a
multi-user environment and I argued what you say above. I eventually
conceded the argument, but am glad to know that I was right all along.
But now I feel bad for passing on wrong information...
-- Brett
http://www.chapelperilous.net/~bmccoy/
---------------------------------------------------------------------------
"The chain which can be yanked is not the eternal chain."
-- G. Fitch
From | Date | Subject | |
---|---|---|---|
Next Message | Chuck Kimber | 2001-03-02 18:33:58 | RE: Last ID |
Previous Message | Tom Lane | 2001-03-02 17:48:35 | Re: Last ID |