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

Just to summarize, I am arguing from a usability perspective, because I
believe the simplest API is one that will last for many releases and not
have to be redesigned, nor require too much adjustment from our users.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> 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, Pennsylvania 19073
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
> 

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