Re: Select nextval problem

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.

In response to

Responses

Browse pgsql-general by date

  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