It suddenly struck me that the problem being complained of in bug #14434
is that dependency.c's findDependentObjects() is handling extension
dependencies incorrectly. It has this logic:
/* * This object is part of the internal implementation of * another
object,or is part of the extension that is the * other object. We have three cases: *
* 1. At the outermost recursion level, we normally disallow * the DROP. (We just ereport
here,rather than proceeding, * since no other dependencies are likely to be interesting.)
*However, there are exceptions. */ if (stack == NULL) { /*
* Exception 1a: if the owning object is listed in * pendingObjects, just release
thecaller's lock and * return. We'll eventually complete the DROP when we *
reachthat entry in the pending list. */ ...
/* * Exception 1b: if the owning object is the extension *
currentlybeing created/altered, it's okay to continue * with the deletion. This allows dropping of
an * extension's objects within the extension's scripts, as * well as corner cases
suchas dropping a transient * object created within such a script. */
...
/* No exception applies, so throw the error */ ...
The bug report occurs because the sequence's extension membership
pg_depend record is hit one recursion level down, so that stack!=NULL.
Instead, we should rearrange this so that "exception 1b" is allowed
whether or not we are at the outermost recursion level. The assumption
is that the sequence creation/upgrade script knows what it's doing and
should not be forced to issue manual ALTER EXTENSION DROP commands
before it can do it.
While looking at that, I wonder if "exception 1a" isn't wrongly placed
as well. Why shouldn't we let that case occur below top level?
regards, tom lane