| 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: | Whole Thread | Raw Message | 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 |