Re: [PATCHES] Proposed patch for sequence-renaming problems
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] Proposed patch for sequence-renaming problems |
Дата | |
Msg-id | 8171.1127934050@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Proposed patch for sequence-renaming problems (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [PATCHES] Proposed patch for sequence-renaming problems
(Bruce Momjian <pgman@candle.pha.pa.us>)
|
Список | pgsql-hackers |
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) 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. 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). > 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). regards, tom lane
В списке pgsql-hackers по дате отправления: