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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
Дата
Msg-id CAH2-Wz=rmUGgdp8K-FB1VRQngHk7MdtKvEATFQ_pP3_N257t8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] CLUSTER command progress monitor