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.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
