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

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

Yeah, I've been wondering about that as well. The original intention
for dependency traversal was that it'd work independently of the ordering
of entries in pg_depend. If it's not doing so, I'd call that a bug in
dependency traversal rather than something the index code needs to be
responsible for.

(Note that this statement doesn't disagree with our issues about needing
to suppress dependency reports in the regression tests; that's because
the order of reports about independent objects can legitimately depend on
the index order. But there shouldn't be any semantic differences.)

regards, tom lane