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-01-17T22:25:27Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > On 2019-Jan-17, Tom Lane wrote: >> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code >> has no hesitation about making multiple entries of that kind. After >> rather cursorily looking at that code, I'm leaning to the position >> that DEPENDENCY_INTERNAL_AUTO is broken-by-design and needs to be >> nuked from orbit. In the cases where it's being used, such as >> partitioned indexes, I think that probably the right design is one >> DEPENDENCY_INTERNAL dependency on the partition master index, and >> then one DEPENDENCY_AUTO dependency on the matching partitioned table. > As I recall, the problem with that approach is that you can't drop the > partition when a partitioned index exists, because it follows the link > to the parent index and tries to drop that. Hm. Still, I can't believe that it's appropriate for a partitioned index to have exactly the same kind of dependency on the master index as it does on the associated table. 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