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  (Martijn van Oosterhout <kleptog@svana.org>)
Список 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 по дате отправления:

Предыдущее
От: Francois Suter
Дата:
Сообщение: Re: Rép. : Re: French translation of 7.3
Следующее
От: Björn Metzdorf
Дата:
Сообщение: Query question