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 <alvhe...@2ndquadrant.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
alter-extension-schema.patch
Description: Binary data
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
