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

On 2018-Dec-18, Peter Geoghegan wrote:

> 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.

Hmm, interesting.  I wonder if this is just a case of never testing this
code under "postgres --ignore-system-indexes".  I can reproduce the
reported problem without your patch by using that flag.  Here's a
recipe:

create extension cube;
create table dep as select ctid as tid,* from pg_depend;
create extension earthdistance;
select tid, deptype, (dep).type, (dep).identity, (ref).type, (ref).identity
  from (select tid, deptype, pg_identify_object(classid, objid, objsubid) as dep,
               pg_identify_object(refclassid, refobjid, refobjsubid) as ref
          from (select ctid as tid, * from pg_depend except select * from dep) a
       ) b;

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