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
-
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