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".
OK. > A relatively simple Plan B would be to use different SQL names for the > variant functions, ie, keep nextval() as is and instead invent, say, > next_value(regclass). Then we tell people to use next_value('foo') > and they don't need to write the cast explicitly. This seems > notationally nicer but a major pain in the neck from the point of view > of documentation and explanation --- for instance, instead of saying > "nextval does this" we'd have to say "next_value and nextval do this". > Not at all sure that I like it better. Agreed, two names is a mess. I still think we shouldn't be hashing this out during beta, but ... What would the final nextval() behavior be? ::regclass binding? How would late binding be done? What syntax? -- 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 2: Don't 'kill -9' the postmaster