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 | 20181218180707.id4chuplqoqzypwe@alvherre.pgsql обсуждение исходный текст |
Ответ на | Fixing findDependentObjects()'s dependency on scan order (regressionsin DROP diagnostic messages) (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages) |
Список | pgsql-hackers |
On 2018-Nov-05, Peter Geoghegan wrote: > I've realized that my patch to make nbtree keys unique by treating > heap TID as a tie-breaker attribute must use ASC ordering, for reasons > that I won't go into here. Now that I'm not using DESC ordering, there > are changes to a small number of DROP...CASCADE messages that leave > users with something much less useful than what they'll see today -- > see attached patch for full details. Some of these problematic cases > involve partitioning: Is there any case of this that doesn't involve DEPENDENCY_INTERNAL_AUTO entries? I wonder if I just haven't broken the algorithm when introducing that, and I worry that we're adding a complicated kludge to paper over that problem. Maybe instead of the depcreate contortions we need to adjust the algorithm to deal with INTERNAL_AUTO objects in a different way. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: