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

From Peter Geoghegan
Subject Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
Date
Msg-id CAH2-Wz=rmUGgdp8K-FB1VRQngHk7MdtKvEATFQ_pP3_N257t8g@mail.gmail.com
Whole thread Raw
In response to Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Dec 18, 2018 at 2:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Interesting.
> > Note that if the standard that we're going to hold a solution to here
> > is "must produce sane output with  --ignore-system-indexes", then my
> > solution will not meet that standard.
>
> Do you mean "same" output, or "sane" output?  I'd certainly expect
> the latter.

I meant sane.

--ignore-system-indexes leads to slightly wrong answers in a number of
the diagnostic messages run by the regression tests (I recall that the
number of objects affected by CASCADE sometimes differed, and I think
that there was also a certain amount of this DEPENDENCY_INTERNAL_AUTO
business that Alvaro looked into). I think that this must have always
been true.

My patch will not improve matters with --ignore-system-indexes. It
merely makes the currently expected output when scanning pg_depend
indexes occur reliably. For better or for worse.

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] CLUSTER command progress monitor