Re: Proposed patch for sequence-renaming problems

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