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

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
Дата
Msg-id CA+HiwqHdMpgfER9omKePCFKXeEWTZ=wsHXzyTiMRuYFrTbSgPw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, Feb 10, 2019 at 2:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Amit Langote <amitlangote09@gmail.com> writes:
> > Reading Tom's reply to my email, I wondered if performDeletion won't
> > do more than what the code is already doing (except calling the right
> > trigger deletion function which the current code doesn't), because the
> > trigger in question is an internal trigger without any dependencies
> > (the function it invokes are pinned by the system)?
>
> A big part of the point here is to not have to have such assumptions
> wired into the fk-cloning code.  But even if that internal dependency is
> the only one the trigger is involved in, there are other steps in
> deleteOneObject that shouldn't be ignored.  For example, somebody
> could've attached a comment to it.

Okay, I hadn't considered that far.  Thanks for explaining.

Regards,
Amit


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Protect syscache from bloating with negative cache entries