Re: Re: Drop all overloads of a function without knowing parameter types
От | Evan Martin |
---|---|
Тема | Re: Re: Drop all overloads of a function without knowing parameter types |
Дата | |
Msg-id | 52F13D25.5050603@realityexists.net обсуждение исходный текст |
Ответ на | Re: Drop all overloads of a function without knowing parameter types (David Johnston <polobo@yahoo.com>) |
Список | pgsql-general |
On 04/02/2014 19:56, David Johnston wrote: > No, they cannot. If the arguments change you are dealing with an entirely > new object. And often you end up keeping the old function around for > backward-compatibility. Of course, I understand that it's a different object, technically, but from the user point of view it may replace the old function. Whether it does or not depends on your upgrade strategy, but in our case it always does. I'm making an argument from the point of view of usability here, not based on the technicalities of what is the "same" object. And I also agree that users should be aware that overloaded functions are different objects. I think there is no danger of anyone missing that fact, even if support for dropping all overloads was added, because it would still require different syntax. The usual CREATE OR REPLACE syntax still wouldn't work. > For an analogy how would your scripts deal with. > > ALTER TABLE table1 RENAME table2; > They would deal with it by doing: DROP TABLE IF EXISTS table1; CREATE TABLE table2 (...); ... if it wasn't for the fact that this would lose all data in the table. For functions this is not a problem. (Of course, you could always add support for "ALTER TABLE table1 RENAME table2 IF NOT ALREADY RENAMED FROM table1" but the use case is not as strong. ;)) > However, I'll concede that since functions are the only class of object that > allow for "name overloading" providing a built-in ability to "DROP ALL > FUNCTION WITH BASE NAME function" - excluding those in pg_catalog - would > have value. No regular expressions just a simple name-without-args literal > match. > > If you are doing version controlled upgrades you should not be using this > function but during the R&D phase I can imagine it would come in quite > handy. > Thank you - that's what I meant. It would make dropping functions consistent with dropping other objects. Whether users then use this in production or only in development is up to them.
В списке pgsql-general по дате отправления: