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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Amit Langote <amitlangote09@gmail.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-09T20:26:55Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Feb-09, Tom Lane wrote:
>> Well, the question that's begged here is exactly why it's okay to remove
>> the trigger and dependency link despite the fact that the constraint needs
>> it.  I suppose the answer is that we'll subsequently insert a new trigger
>> implementing the same constraint (and internally-linked to it)?  That
>> information is what I'd like to have in the comment.

> Well, the answer is that the trigger is no longer needed.  This is an
> action trigger, i.e. it's attached to the referenced relation; and the
> action is making an independent table become a partition.  Since the
> partition is reachable by the action trigger that goes through the
> parent table, we no longer need the action trigger that goes directly to
> the partition.

Oh ... then why don't we go ahead and get rid of the constraint entry,
too?

			regards, tom lane


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.