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

On Tue, Dec 18, 2018 at 10:07 AM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> 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.

Well, you also have cases like this:

--- a/contrib/earthdistance/expected/earthdistance.out
+++ b/contrib/earthdistance/expected/earthdistance.out
@@ -972,7 +972,7 @@ SELECT abs(cube_distance(ll_to_earth(-30,-90),
'(0)'::cube) / earth() - 1) <

drop extension cube; -- fail, earthdistance requires it
ERROR: cannot drop extension cube because other objects depend on it
-DETAIL: extension earthdistance depends on extension cube
+DETAIL: extension earthdistance depends on function cube_out(cube)

This is a further example of "wrong, not just annoying". Technically
this is a broader problem than DEPENDENCY_INTERNAL_AUTO, I think,
though perhaps not too much broader.
--
Peter Geoghegan