Skip site navigation (1) Skip section navigation (2)

Re: AW: [HACKERS] Sequence objects have no global currval operator?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at>
Cc: "hackers(at)postgreSQL(dot)org" <hackers(at)postgreSQL(dot)org>
Subject: Re: AW: [HACKERS] Sequence objects have no global currval operator?
Date: 1998-07-14 14:28:46
Message-ID: 16192.900426526@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> writes:
> What do you think of making currval return exactly this, only in the 
> case where nextval was not yet called by this client ?

I don't think that would be helpful.  If what you want is last_value
then the *only* safe way to get it is to use SELECT last_value.
Using currval in the way you suggest would be asking for trouble ---
your code will work until you add a nextval somewhere in the same
client, and then it will fail.  Subtly.

As defined, currval is only useful for specialized uses, such as
assigning the same newly-allocated sequence number to multiple
fields or table rows.  For example you could do
	INSERT INTO table1 VALUES(nextval('seq'), ....);
	INSERT INTO table2 VALUES(currval('seq'), ....);
	INSERT INTO table3 VALUES(currval('seq'), ....);
This is perfectly correct and safe: all three tables will get the same
uniquely-allocated sequence number regardless of what any other clients
may be doing.  You could also read back the assigned value with
	SELECT nextval('seq');
and then insert the value literally into subsequent commands, but
that way requires an extra round trip to the server.

currval is not useful for inquiring about what other clients are doing,
and I think we are best off to leave it that way to avoid confusion.
I was only complaining because I didn't understand about last_value
at the start of this thread.

			regards, tom lane

pgsql-hackers by date

Next:From: Andreas ZeugswetterDate: 1998-07-14 14:52:32
Subject: Re: [HACKERS] Re: Recent updates [to union]
Previous:From: Tom LaneDate: 1998-07-14 14:10:05
Subject: Re: [HACKERS] HPUX Port

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group