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

Hi,

Sorry for being late at the party=E2=80=A6 been distracted away=E2=80=A6
=20=20=20=20=20=20=20
Bruce Momjian <bruce@momjian.us> writes:
> On Fri, Jun 22, 2012 at 10:37:10PM -0400, Tom Lane wrote:
>> jeff@pgexperts.com writes:
>> > DROP and CREATE extension appear to work fine, but if you ALTER EXTENS=
ION
>> > postgis SET SCHEMA foo, it leaves a few relations behind.
>>=20
>> What it seems to be leaving behind is indexes ... also relation rowtypes.
>>=20
>> 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 =C3=81lvaro did try with his _oid() attempt that
failed.

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