On Wed, 28 Sep 2005, Tom Lane wrote:
> I wrote:
> > The only other thing that's been discussed is the SQL2003 syntax
> > NEXT VALUE FOR sequencename
> > but this is in fact just syntactic sugar for something functionally
> > equivalent to nextval('sequencename'::regclass).
>
> I have to take that back. It's not just syntactic sugar for nextval(),
> because the SQL2003 spec says
>
> : If there are multiple instances of <next value expression>s specifying
> : the same sequence generator within a single SQL-statement, all those
> : instances return the same value for a given row processed by that
> : SQL-statement.
>
> So it's really sort of a magic combination of nextval() and currval().
> To meet the spec semantics, we'd need some sort of layer over nextval()
> that would keep track of whether a new value should be obtained or not.
>
> I don't think we should use the spec syntax until we're prepared to
> meet the spec semantics, so NEXT VALUE FOR as part of the current patch
> seems "out".
Well, AFAICT, the only part of the spec we cannot implement is what you
quote above. Therefore, why can't we support NEXT VALUE FOR seqname and
reject table creation/alteration which would add more than one reference
to the same sequence. That will allow us to avoid an intermediate step
in getting to the SQL2003 syntax. Having to support three different
sequence incrementation mechanisms for three flavours of PostgreSQL is
going to be a real PITA.
Thanks,
Gavin