Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
| От | Alvaro Herrera |
|---|---|
| Тема | Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages) |
| Дата | |
| Msg-id | 201901190201.fmtf2fdn2rec@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages) (Peter Geoghegan <pg@bowt.ie>) |
| Ответы |
Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
|
| Список | 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 по дате отправления: