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)
|
Список | 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 по дате отправления: