Re: [PATCHES] Proposed patch for sequence-renaming problems

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I am thinking we need to have nextval('') do early binding and have
> nextval(''::text) (or some other name) do late binding.

You can't have that in exactly that form, because text is invariably
the preferred resolution of unknown-type literals, and we certainly
dare not tinker with that rule. There is therefore no way that the
above two syntaxes are going to act differently. If we were willing to
change the name of the existing nextval functionality, we could have,
say,

nextval(regclass)
nextval_late(text)

where the latter is the new spelling of the existing function.
To make this work without breaking existing dumps (which will all say
"nextval('foo'::text)" it'd be necessary to introduce an implicit cast
from text to regclass. That scares me a fair amount --- cross category
implicit casts are generally evil. However, it might be OK given that
there are so few functions that take regclass arguments.

This still wouldn't put us in a place where existing dumps are
automatically fixed up during import. We'd parse the expressions as
nextval('foo'::text::regclass), which will work but it's effectively
still late-binding --- the actual constant is just text not regclass.
There's no way to fold it down to 'foo'::regclass automatically because
(1) we don't do constant-folding before storing expressions, and (2)
even if we did, the text to regclass cast cannot be marked immutable
(it's only stable). So people would still have to go through and change
their schemas by hand to get to the early-binding behavior.

Given all that, it seems the better part of valor to leave nextval()
as-is: there's too much risk and too little reward in that path. The
next best alternative is to use some other name than nextval for the
early-binding form, and to encourage people to move to the new name.
Same amount of manual schema-updating, much less risk of breaking existing
code due to unforeseen side-effects, much less confusion about what does
which.

BTW, I've gone back to thinking that next_value is the best alternative
spelling, because it calls to mind the SQL standard syntax NEXT VALUE
FOR (which I assume we'll want to support eventually).

> Also, when there is no standard, Oracle is the standard, and for Oracle,
> nextval is early binding.

Oracle does not spell nextval in any of these ways, so that argument
carries little weight. If we were using exactly the Oracle syntax, then
sure, but we're not. Also, we have to put some weight on backward
compatibility with our own past practice.

So on the whole I like leaving nextval() as-is and introducing a
separate function next_value(regclass).

regards, tom lane