Gavin Sherry wrote: > > 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.
Oh, if we went in that direction, how would we fix loading previous dumps? Isn't NEXT VALUE for going to map internally to the early-binding version of nextval(). I am thinking mucking with nextval() and its casts is going to be required for ALTER SCHEMA RENAME to work with any kind of reliability. -- 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
