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