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

  1. Redesign the partition dependency mechanism.

  2. Fix trigger drop procedure

  3. Sort the dependent objects before recursing in findDependentObjects().

  4. Avoid sometimes printing both tables and their columns in DROP CASCADE.