Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-12-18T18:07:07Z
Lists: pgsql-hackers
On 2018-Nov-05, Peter Geoghegan wrote: > I've realized that my patch to make nbtree keys unique by treating > heap TID as a tie-breaker attribute must use ASC ordering, for reasons > that I won't go into here. Now that I'm not using DESC ordering, there > are changes to a small number of DROP...CASCADE messages that leave > users with something much less useful than what they'll see today -- > see attached patch for full details. Some of these problematic cases > involve partitioning: Is there any case of this that doesn't involve DEPENDENCY_INTERNAL_AUTO entries? I wonder if I just haven't broken the algorithm when introducing that, and I worry that we're adding a complicated kludge to paper over that problem. Maybe instead of the depcreate contortions we need to adjust the algorithm to deal with INTERNAL_AUTO objects in a different way. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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