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.
