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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Date: 2018-12-18 21:20:53
Message-ID: 20181218212053.4vqcmmcicbzr2jyc@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-12-18 21:36:51 insensitive collations
Previous Message Peter Eisentraut 2018-12-18 21:12:05 WRITE_*_ARRAY macros for outfuncs.c