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

Tom Lane wrote:
> 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)

This is the first proposal I like. 99% of users think that nextval() is
doing early binding (or never thought of it), so I think moving to that
syntax is a win. Is late/dynamic/string/virtual the right suffix?

> 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.

I am thinking we should hard-code something in the backend so if the
function oid is nextval/currval/setval, we strip off any text casting
internally. These functions are already pretty special in their usage
so I don't see a problem in fixing it this way.

Ideally we could do a test in the grammar and strip off the ::text
there.

> 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).

True, but it doesn't have the standard behavior. Would we change that
when we add NEXT VALUE?

> > 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).

I disagree. nextval() is too embedded in people's thinking to make them
change when we have the ability to have it do the _right_ _thing_, and
give a "dynamic" alternative for those you need it.

Also, Oracle does use nextval as my_docs_seq.nextval so the use of that
keyword is a good policy to continue.

--
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