Rod Taylor <pg@rbt.ca> 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 they're asking for.
What would make sense to me is to keep the current behavior for a
nextval() call written as a function (either the present syntax with a
text-string argument, or a hypothetical improved version that exposes
the sequence object more directly). But do it the spec's way for the
NEXT VALUE FOR syntax. Then people would have the choice of which
behavior they wanted, and also we'd not be taking any
backwards-compatibility hit.
How we do what the spec wants isn't entirely clear, but maybe we could
link all the supposed-to-track-each-other occurrences of NEXT VALUE FOR
late in the planning stage or during executor startup, somewhat like
what happens with aggregate functions.
regards, tom lane