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

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jeff(at)pgexperts(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Date: 2012-09-12 09:51:43
Message-ID: m2k3vzwouo.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

Sorry for being late at the party… been distracted away…

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Fri, Jun 22, 2012 at 10:37:10PM -0400, Tom Lane wrote:
>> jeff(at)pgexperts(dot)com writes:
>> > DROP and CREATE extension appear to work fine, but if you ALTER EXTENSION
>> > postgis SET SCHEMA foo, it leaves a few relations behind.
>>
>> What it seems to be leaving behind is indexes ... also relation rowtypes.
>>
>> A bit of looking shows that ALTER EXTENSION SET SCHEMA calls
>> AlterObjectNamespace_oid on the table. AlterObjectNamespace_oid
>> calls AlterRelationNamespaceInternal, and nothing else. In comparison,
>> ALTER TABLE SET SCHEMA (AlterTableNamespace) calls
>> AlterRelationNamespaceInternal and about four other things. I'm not
>> sure if this was broken before the last round of refactoring in this
>> area, but for sure it's broken now.

Looking at that code, my theory of how we got there is that in the
submitted extension patch I did only use DEPENDENCY_INTERNAL and Tom
introduced the much better DEPENDENCY_EXTENSION tracking. With the
former, indexes and sequences and constraints where found in the
dependency walking code, but only the main relation is now registered in
the later model.

I need to do some testing about dependency tracking on SERIAL generated
sequences compared to manually created sequences in extension scripts, I
think we track sequences directly only in the manual case.

I think we need to share more code in between
AlterRelationNamespaceInternal and AlterTableNamespace, but I'm not sure
if that's not exactly what Álvaro did try with his _oid() attempt that
failed.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Marko Tiikkaja 2012-09-12 11:01:40 Re: BUG #7516: PL/Perl crash
Previous Message Martin Pitt 2012-09-12 07:25:12 Re: BUG #7532: cannot update to 9.2