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

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(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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

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