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                        |               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to