Gavin Sherry wrote:
> > 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.
Well, that is an _excellent_ point. We would have three mechanisms,
which is confusing.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
