Re: Select nextval problem
От | SZUCS Gábor |
---|---|
Тема | Re: Select nextval problem |
Дата | |
Msg-id | 006701c296de$02b52fd0$0a03a8c0@fejleszt2 обсуждение исходный текст |
Ответ на | Select nextval problem (MT <mt@open2web.com>) |
Ответы |
Re: Select nextval problem
|
Список | 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@svana.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.
В списке pgsql-general по дате отправления: