Re: BUG #14706: Dependencies not recorded properly for base types

On Thu, Jun 15, 2017 at 1:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Thu, Jun 15, 2017 at 9:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> ... but yeah, as long as we're supporting it at all, that shouldn't
>>> happen. Thanks for the report!
>
>> Tom, are you working on a patch? At quick glance, this is just missing a
>> call to recordDependencyOn() in SetFunctionReturnType().
>
> No, I'm going to bed soon. If you want to fix this, have at it.

Okay, here you do. The other two call sites of SetFunctionReturnType
involve triggers and PLs, but those are able to consider correctly
dependencies. For PLs:
=# CREATE FUNCTION mylang_call_handler() RETURNS opaque language c AS
'$libdir/plpgsql', $function$plpgsql_call_handler$function$;
CREATE FUNCTION
=# CREATE language mylang HANDLER mylang_call_handler;
WARNING: 42809: changing return type of function mylang_call_handler
from opaque to language_handler
LOCATION: CreateProceduralLanguage, proclang.c:283
CREATE LANGUAGE
=# drop function mylang_call_handler ();
ERROR: 2BP01: cannot drop function mylang_call_handler() because
other objects depend on it
DETAIL: language mylang depends on function mylang_call_handler()
HINT: Use DROP ... CASCADE to drop the dependent objects too.
LOCATION: reportDependentObjects, dependency.c:963

For triggers:
=# CREATE FUNCTION fn_x_before () RETURNS opaque AS $$
BEGIN
return NEW;
END;
$$ LANGUAGE plpgsql;
CREATE FUNCTION
=# CREATE TABLE aa (a int);
CREATE TABLE
=# CREATE TRIGGER aa_before BEFORE INSERT ON aa FOR EACH ROW EXECUTE
PROCEDURE fn_x_before();
WARNING: 01000: changing return type of function fn_x_before from
opaque to trigger
LOCATION: CreateTrigger, trigger.c:551
CREATE TRIGGER
=# DROP FUNCTION fn_x_before ;
ERROR: 2BP01: cannot drop function fn_x_before() because other
objects depend on it
DETAIL: trigger aa_before on table aa depends on function fn_x_before()
HINT: Use DROP ... CASCADE to drop the dependent objects too.
LOCATION: reportDependentObjects, dependency.c:963

Attached is an idea of patch, inputs welcome. Another idea would be to
deprecate things on HEAD and cause an ERROR when doing such things.
--
Michael