Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Peter Geoghegan <pg@bowt.ie>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-10T21:06:29Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > On 2019-Feb-10, Peter Geoghegan wrote: >> On Sun, Feb 10, 2019 at 8:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Just to be be clear, my inclination is to do nothing about this in v11. >>> It's not apparent to me that any fix is possible given the v11 dependency >>> data, at least not without downsides that'd likely outweigh the upsides. >>> We've not seen field complaints about these problems. >> I thought that you might have had a trick up your sleeve for v11, >> although I had no idea how that would be possible without making sure >> that partition dependencies came in pairs to begin with. :-) > If we disregard the scenario were people downgrade across minor > versions, it's likely possible to produce SQL queries to transform from > the old arrangement to the new one, and include those in release notes > or a wiki page; not for this week's minors (ENOTIME) but maybe for the > next one. Dunno ... we couldn't force people to do that, so the server would have to be prepared to cope with either arrangement, which seems like an impossible mess. regards, tom lane
Commits
-
Redesign the partition dependency mechanism.
- 1d92a0c9f7dd 12.0 landed
-
Fix trigger drop procedure
- cc126b45ea5c 11.2 landed
- cb90de1aac18 12.0 landed
-
Sort the dependent objects before recursing in findDependentObjects().
- f1ad067fc3ae 12.0 landed
-
Avoid sometimes printing both tables and their columns in DROP CASCADE.
- 9194c4270b28 12.0 landed