Anssi Kääriäinen <anssi.kaariainen@thl.fi> writes:
> The rename is an error on my part, sorry for that. Renaming can be done, but
> dropping is not possible even after rename.
Ok, that matches my tests and reading fo the code.
> But a function in a package can
> be CREATE OR REPLACEd, and after that the function can be dropped. COR
> should be restricted in the same way as DROP is. I will check if this is
> still a problem with the latest patch.
There, I've been missing exactly what Alvaro has been telling us about
here, that CREATE OR REPLACE on pg_proc will drop all known dependencies
then recreate them, using deleteDependencyRecordsFor(). As Tom
explained this week, DEPENDENCY_INTERNAL are working in the reverse way
than usual, which means that the function/extension dependency were lost
here.
I've fixed the case by having the code remember the function's extension
if any, and restore it along with the other dependencies. Here's my
test case that now passes:
~:5490=# \dx+ lo
Objects in extension "lo"
Object Class | Object OID | Object Description
--------------+------------+---------------------------------
pg_proc | 33082 | function utils.lo_manage()
pg_proc | 33081 | function utils.lo_oid(utils.lo)
pg_type | 33080 | type utils.lo
(3 rows)
~:5490=# CREATE OR REPLACE FUNCTION utils.lo_manage()
RETURNS pg_catalog.trigger
AS '$libdir/lo'
LANGUAGE C;
CREATE FUNCTION
~:5490=# \dx+ lo
Objects in extension "lo"
Object Class | Object OID | Object Description
--------------+------------+---------------------------------
pg_proc | 33082 | function utils.lo_manage()
pg_proc | 33081 | function utils.lo_oid(utils.lo)
pg_type | 33080 | type utils.lo
(3 rows)
(before the fix it would have missed the utils.lo_manage() function in
this second listing).
The fix is in my git repository and in the attached v26 patch,
containing also the fixes from yesterday. Thanks again for your
complete testing!
> Another problem is that you can ALTER FUNCTION test() SET SCHEMA =
> something_else, and you can alter the functions search_path, which could be
> a problem for non-relocatable extensions. Even if the schema is changed,
> dropping extension / altering extension will work as expected. The function
> is just in different schema than the extension. But, both of these IMO fall
> in the category "don't do that".
Agreed. And on the other hand, I can image cases where as a work around
you'll be glad that you still have "full power" on the extension's objects.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
