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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-01-17T22:15:54Z
Lists: pgsql-hackers
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.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Redesign the partition dependency mechanism.

  2. Fix trigger drop procedure

  3. Sort the dependent objects before recursing in findDependentObjects().

  4. Avoid sometimes printing both tables and their columns in DROP CASCADE.