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