On Thu, Feb 17, 2022 at 7:30 PM David G. Johnston <david.g.johnston@xxxxxxxxx> wrote:
On Thu, Feb 17, 2022 at 6:17 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:"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.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.
