From: | SZUCS Gábor <surrano(at)mailbox(dot)hu> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Select nextval problem |
Date: | 2002-11-28 12:59:34 |
Message-ID: | 006701c296de$02b52fd0$0a03a8c0@fejleszt2 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Martijn,
your mail arrived to me as two attachments, with no message body. Could you
do something about this?
I think I wasn't clear enough. Under the term "after", I meant time. So if
you
INSERT ... nextval... -- #1
...
INSERT ... nextval... -- #(n+1)a, or
INSERT ... VALUES (currval('...')+k); -- #(n+1)b, where k>0
then neither of the following:
SELECT ... currval...
SELECT ... ORDER BY id DESC LIMIT 1
won't be able to tell the id of INSERT #1. This is what I meant. I.e.
'currval' is guaranteed to have a usable value only right after the INSERT
in question. It's trivial (for me), I just noted it to make things sure. But
still, I may be wrong. Feel free to tell me if this explanation is still
wrong.
G.
--
while (!asleep()) sheep++;
---------------------------- cut here ------------------------------
----- Original Message -----
From: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>
Sent: Thursday, November 28, 2002 12:41 AM
> SELECT * FROM product WHERE prodid = currval('prodid_seq');
> SELECT * FROM product ORDER BY prodid DESC LIMIT 1;
>
> Both of these, however, assume that you haven't inserted any rows after
the
> one in question.
Wrong. The second one does. The first guarenteed to return what the earlier
nextval() returned. It is therefore the recommended method. Lookup the
documentation for more details.
From | Date | Subject | |
---|---|---|---|
Next Message | Björn Metzdorf | 2002-11-28 13:59:19 | Query question |
Previous Message | Francois Suter | 2002-11-28 12:50:05 | Re: R=?ISO-8859-1?B?6Q==?=p. : Re: French translation of 7.3 |