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

On 2019-Feb-09, Tom Lane wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> 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.
> 
> > Yeah, it's deleting the INTERNAL dependency, because otherwise the
> > trigger deletion is (correctly) forbidden, since the constraint depends
> > on it.
> 
> 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.

Conversely, when we detach a partition, we create an action trigger that
wasn't there before.

I'll put this in the comment.

> > Perhaps it'd be good to have it be more targetted: make sure it
> > only deletes that dependency row and not any others that the trigger
> > might have (though I don't have it shouldn't have any.  How could it?)  I'd do
> > that by adding a new function
> 
> I'm not sure that'd be an improvement, especially in light of the
> hazard that the trigger might somehow have acquired extension and/or
> partition dependencies that'd also cause issues.

Good point.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services