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>
Subject: Re: Fixing findDependentObjects()'s dependency on scan order
 (regressions in DROP diagnostic messages)
In-reply-to: <20190209155613.GA2091@alvherre.pgsql>
References: <20190209155613.GA2091@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Sat, 09 Feb 2019 12:56:13 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5942.1549728638.1@sss.pgh.pa.us>
Date: Sat, 09 Feb 2019 11:10:38 -0500
Message-ID: <5943.1549728638@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Feb-09, Tom Lane wrote:
>> No, that's still the back end of the deletion machinery, and in particular
>> it would fail to clean pg_depend entries for the trigger.  Going in by the
>> front door would use performDeletion().  (See deleteOneObject() to get
>> an idea of what's being possibly missed out here.)

> This patch I think does the right thing.

(squint ...) Don't much like the undocumented deleteDependencyRecordsFor
call; that looks like it's redundant with what deleteOneObject will do.
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.

Also, I suspect you might need a second CCI after the performDeletion
call, in case the loop iterates?

			regards, tom lane