[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-bugs
Subject:    Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2012-08-31 21:50:41
Message-ID: 22747.1346449841 () sss ! pgh ! pa ! us
[Download RAW message or body]

Alvaro Herrera <alvherre@2ndquadrant.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


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[prev in list] [next in list] [prev in thread] [next in thread]