From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | jeff <jeff(at)pgexperts(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations |
Date: | 2012-08-31 15:28:35 |
Message-ID: | 1346425015-sup-3266@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Excerpts from Tom Lane's message of vie jun 22 22:37:10 -0400 2012:
> jeff(at)pgexperts(dot)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.
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.
FWIW this bug seems to have been introduced in the initial extensions
commit, d9572c4e3b474031060189050e14ef384b94e001. Prior to that we had
ExecAlterObjectSchemaStmt calling AlterTableNamespace directly.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | gravesl | 2012-08-31 15:49:57 | BUG #7513: Cluster install failed |
Previous Message | Tom Lane | 2012-08-31 14:59:03 | Re: BUG #6758: ./configure script sets HAVE_WCSTOMBS_L 1 |