| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) |
| Date: | 2019-02-09 16:10:38 |
| Message-ID: | 5943.1549728638@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2019-Feb-09, Tom Lane wrote:
>> No, that's still the back end of the deletion machinery, and in particular
>> it would fail to clean pg_depend entries for the trigger. Going in by the
>> front door would use performDeletion(). (See deleteOneObject() to get
>> an idea of what's being possibly missed out here.)
> This patch I think does the right thing.
(squint ...) Don't much like the undocumented deleteDependencyRecordsFor
call; that looks like it's redundant with what deleteOneObject will do.
I think you're doing it to get rid of the INTERNAL dependency so that
deletion won't recurse across that, but why is that a good idea? Needs
a comment at least.
Also, I suspect you might need a second CCI after the performDeletion
call, in case the loop iterates?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-02-09 16:37:34 | Re: libpq compression |
| Previous Message | Alvaro Herrera | 2019-02-09 15:56:13 | Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages) |