Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

On 2019-Jan-17, Tom Lane wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.

So there are three necessary features:
* The partition can be dropped, which takes down the index partition
* The master index can be dropped, which takes down the index partition
* The index partition must never be allowed to be dropped on its own.

There is a symmetry to these that led me to have the same kind of
dependency from the index partition to the other two.

I'm now wondering if it would work to have the one from index partition
to table partition as DEPENDENCY_AUTO and the one from index partition
to parent index as DEPENDENCY_INTERNAL_AUTO. I stared at a lot of
possible dependency graphs, but I'm not sure if this one was one of
them.

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