Re: [PATCHES] Proposed patch for sequence-renaming problems - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [PATCHES] Proposed patch for sequence-renaming problems |
Date | |
Msg-id | 200509290223.j8T2N1u11778@candle.pha.pa.us Whole thread Raw |
In response to | Re: [PATCHES] Proposed patch for sequence-renaming problems (Bruce Momjian <pgman@candle.pha.pa.us>) |
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
pgsql-hackers by date: