Rod Taylor [EMAIL PROTECTED] writes:
NEXT VALUE FOR and CURRENT VALUE FOR where CURRENT is an unreserved
keyword and VALUE is not reserved in any way (ident with comparison to
value).
I see one pretty big problem with this: the SQL2003 spec says clearly
that multiple occurrences of NEXT VALUE
On Fri, 2004-05-07 at 14:38, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
NEXT VALUE FOR and CURRENT VALUE FOR where CURRENT is an unreserved
keyword and VALUE is not reserved in any way (ident with comparison to
value).
I see one pretty big problem with this: the SQL2003 spec
Rod Taylor [EMAIL PROTECTED] writes:
Does that mean the below insert should give both col1 and col2 the same
value?
CREATE TABLE test (
col1 integer DEFAULT NEXT VALUE FOR t_seq,
col2 integer DEFAULT NEXT VALUE FOR t_seq
);
INSERT INTO TABLE DEFAULT VALUES;
AFAICS that's what
Rod Taylor [EMAIL PROTECTED] writes:
Isn't there a statement level memory location that we could shove a
boolean variable?
Not per se, and anyway remember that this behavior is per sequence
generator not global.
I was just mentally designing something that I think might work. We
need two data
This all assumes that associating the NEXTVALUE state with an EState
is a good approximation of the spec's statements about how often to
advance the sequence counter. I think it is all right for simple cases
That is an awful lot of work to do in order to avoid implementing
IDENTITIES and
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
I will probably hold it in the queue until Tom returns.
