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