Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
Date
Msg-id 201901190201.fmtf2fdn2rec@alvherre.pgsql
Whole thread Raw
In response to Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
List pgsql-hackers
On 2019-Jan-18, Peter Geoghegan wrote:

> On Fri, Jan 18, 2019 at 3:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> > * There is still instability in which object you get told to drop
> > when attempting to drop an index partition or trigger, as a consequence
> > of there being two possible DEPENDENCY_INTERNAL_AUTO targets.  I still
> > feel that the right fix there involves changing the design for what
> > dependency types we store, but I've not worked on it yet.
> 
> I thought that your ALTER OBJECT DEPENDS ON EXTENSION example made the
> case for fixing that directly inarguable. I'm slightly surprised that
> you're not fully convinced of this already. Have I missed some
> subtlety?

I agree that it needs fixed, but I don't think we know what to change it
*to*.  The suggestion to use one AUTO and one INTERNAL seems to me to
break some use cases.  Maybe one INTERNAL and one INTERNAL_AUTO works
well, not sure.

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


pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Next
From: Edmund Horner
Date:
Subject: Re: Tid scan improvements