| From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-09-13 15:28:29 |
| Message-ID: | m2ipbiuele.fsf@2ndQuadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Well, what I saw was that both the table and its SERIAL-generated
> sequence got an DEPENDENCY_EXTENSION row in pg_depend, which is exactly
> what (IMV) causes the problem. One of my proposals is to tweak the code
> to avoid that row (but if we do that, then we need to do something about
> databases that contain such rows today).
Ah yes, indeed.
I think we shouldn't change the content of pg_depend lightly here, and
that we should rather specialize AlterObjectNamespace_oid() to skip
caring about sequences. The other objects that get moved by
AlterTableNamepace other than the table itself and its sequences are
Indexes and Constraints. Owned Sequence (serial) will get cared of by
the extension dependency walking code.
I'm going to have a try at that.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-09-13 16:39:18 | Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case) |
| Previous Message | Amit Kapila | 2012-09-13 13:18:47 | Re: BUG #7533: Client is not able to connect cascade standby incase basebackup is taken from hot standby |