"David G. Johnston" <david.g.johnston@xxxxxxxxx> writes:
> Maybe, but the behavior does exist but is bugged in its current state.
> Whether it is advisable for users to use this feature is immaterial, the
> bug needs to be fixed so that is works as documented for those that choose
> to do so.
There is no bug here; it's operating as designed and documented.
Maybe the docs need some refinement.
The way this is intended to work is that if you have a function that
depends on an extension -- say by using an extension-defined data
type -- then the *default* behavior is that you'd have to say CASCADE
in order to drop the extension. The point of the ALTER DEPENDS ON
functionality is to declare that you don't want that behavior, but
would like the function to go away silently (ie, without CASCADE)
when the extension is dropped. Thus:
test=# create extension cube;
CREATE EXTENSION
test=# create function myfunc(cube) returns int as 'select cube_dim($1)' language sql;
CREATE FUNCTION
test=# drop extension cube;
ERROR: cannot drop extension cube because other objects depend on it
DETAIL: function myfunc(cube) depends on type cube
HINT: Use DROP ... CASCADE to drop the dependent objects too.
test=# drop extension cube cascade;
NOTICE: drop cascades to function myfunc(cube)
DROP EXTENSION
versus
test=# create extension cube;
CREATE EXTENSION
test=# create function myfunc(cube) returns int as 'select cube_dim($1)' language sql;
CREATE FUNCTION
test=# alter function myfunc(cube) depends on extension cube;
ALTER FUNCTION
test=# drop extension cube;
DROP EXTENSION
test=# \df myfunc
List of functions
Schema | Name | Result data type | Argument data types | Type
--------+------+------------------+---------------------+------
(0 rows)
That's acting as designed and we're not going to change it
for fear of breaking existing use-cases. However, maybe
the use of "automatic" in the documentation isn't sufficiently
clear.
Now, if you have a function that has some internal,
not-visible-to-the-dependency-system extension dependency,
it's true that you don't get any protection against that:
test=# create extension cube;
CREATE EXTENSION
test=# create function myfunc(int) returns int as 'select cube_dim(cube($1,$1))' language sql;
CREATE FUNCTION
test=# drop extension cube;
DROP EXTENSION
However, the function wasn't dropped, so it's hard to argue that the
dependency system didn't do its job. The function is still there,
even though it will fail at execution:
test=# select myfunc(42);
ERROR: function cube(integer, integer) does not exist
LINE 1: select cube_dim(cube($1,$1))
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
QUERY: select cube_dim(cube($1,$1))
CONTEXT: SQL function "myfunc" during inlining
You just need to re-install the extension, so it's not like you lost much:
test=# create extension cube;
CREATE EXTENSION
test=# select myfunc(42);
myfunc
--------
1
(1 row)
In any case, ALTER DEPENDS ON EXTENSION is not meant to provide
protection against that scenario. The best thing we have for
one-off internal dependencies right now is that new-style SQL
functions do expose them:
test=# drop function myfunc(int);
DROP FUNCTION
test=# create function myfunc(int) returns int begin atomic; select cube_dim(cube($1,$1)); end;
CREATE FUNCTION
test=# drop extension cube;
ERROR: cannot drop extension cube because other objects depend on it
DETAIL: function myfunc(integer) depends on function cube(double precision,double precision)
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Another possible approach is to group such functions into
their own extension, which you could make dependent on cube.
regards, tom lane
