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 the caller's lock and
* return. We'll eventually complete the DROP when we
* reach that entry in the pending list.
*/
...
/*
* Exception 1b: if the owning object is the extension
* currently being 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 such as 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
