Re: alter function/procedure depends on extension

On Thu, Feb 17, 2022 at 7:30 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Thu, Feb 17, 2022 at 6:17 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> 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.
>
>
> I don't get why we bothered then. We have to now ignore any possibility of
> using RESTRICT here in order to avoid having the DROP EXTENSION user add
> CASCADE to their command? At least the "black box" reason added a
> capability to the system that wasn't already available.
>
>
I think I finally understand this. I'm unclear on why ALTER EXTENSION ADD
couldn't be used here instead of ALTER FUNCTION but for now I'll assume it
boils down to permissions.

The primary goal here is for extensions that create "user space"
functions/procedures to include them as effective members of the
extension. So long as the only dependencies created on the extension are
by the extension itself, and all of them are altered in this manner, then
executing drop extension restrict will just work. If any other
dependencies exist then because we are in restrict mode the drop will
fail. Being forced to add cascade to the command would drop these
uncontrolled routines as well; that is what we are trying to avoid.

So I guess my main complaint with the design is the choice of the word
"depend" since dependencies already have well established behaviors
associated with them that this particular design deviates from. Calling
them "members" has a similar problem (otherwise alter extension would
simply work and solve this problem nicely) but it seems better than
"depends" - though having the description wording use "member" and the
clause say "depends" isn't great either...adding a third category is
out-of-scope at this point.

David J.