Re: [PATCHES] Proposed patch for sequence-renaming problems - Mailing list pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073