Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Excerpts from Alvaro Herrera's message of vie ago 31 16:25:40 -0400 2012:
>> This doesn't actually work though: it's trying to move sequences twice.
>> Not sure what the right fix for this is ... still looking.

> Besides being listed with deptype=extension for the extension in
> question, the sequence has a deptype=auto entry for the column, which
> leads to it being moved twice.

Ah so.

> 2. During ALTER EXTENSION execution, skip moving objects that have
> already been moved. Not really sure how this would be implemented;

+1 for this approach. I'm a bit surprised we didn't hit this before,
because in general there can be multiple dependency chains leading from
object A to object B. Most code that is doing more than trivial
dependency-walking has to be prepared to cope with reaching the same
object multiple times.

Implementation like this seems reasonable:

> 4. Maybe we could have AlterRelationNamespaceInternal check what the
> current namespace is for the object, and do nothing if it's already the
> target namespace.

We already have some such shortcut for ALTER OWNER, IIRC, so why not
for SET SCHEMA as well? I suspect that AlterRelationNamespaceInternal
is not the only function that needs it, too.

regards, tom lane