Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-09T17:51:38Z
Lists: 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
Commits
-
Redesign the partition dependency mechanism.
- 1d92a0c9f7dd 12.0 landed
-
Fix trigger drop procedure
- cc126b45ea5c 11.2 landed
- cb90de1aac18 12.0 landed
-
Sort the dependent objects before recursing in findDependentObjects().
- f1ad067fc3ae 12.0 landed
-
Avoid sometimes printing both tables and their columns in DROP CASCADE.
- 9194c4270b28 12.0 landed