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