Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Date
Msg-id 17113.1547763927@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD
Next
From: Mikael Kjellström
Date:
Subject: Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD