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

Excerpts from Alvaro Herrera's message of vie ago 31 12:26:50 -0400 2012:
> Excerpts from Tom Lane's message of vie ago 31 12:17:59 -0400 2012:
> > Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > > Aha, I see the bug. It seems the split for AlterObjectNamespace_oid
> > > related to tables was done at the wrong level: there should be a new
> > > AlterTableNamespace_internal call that does all the extra stuff, and
> > > which is to be called from AlterObjectNamespace_oid.
> >
> > Sounds reasonable to me. Are you going to fix it, or should I? If
> > it was introduced in the extensions patch then it's my fault ...
>
> I'm looking into it.

Here's a patch. Note I'm not attempting to create a regression test
because that seems to involve setting up a fake extension which I don't
know how to do (would be too messy, I think). So I tested it by having
isn--1.0.sql create a table with a primary key: create the extension,
alter it to move to a new schema, drop the original schema (public). If
I then try to dump the database, pg_dump in current HEAD fails with "no
schema with OID 2200" (not verbatim; OID is for the old public schema).
It seems to me that this is exactly what was reported initially. Also I
verified that psql's \d reports the inconsistency of the table and its
PK.

Patched code works fine.

For some reason, AlterSeqNamespaces was being passed a schema name.
This wasn't used and was not possible to keep in the patched code so I
just removed it.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services