Hi,
Sorry for being late at the party… been distracted away…
Bruce Momjian <br...@momjian.us> writes:
> On Fri, Jun 22, 2012 at 10:37:10PM -0400, Tom Lane wrote:
>> j...@pgexperts.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
