Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) |
| Дата | |
| Msg-id | 24135.1549732381@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages) (Amit Langote <amitlangote09@gmail.com>) |
| Ответы |
Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)
|
| Список | pgsql-hackers |
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.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера