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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
