From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: 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: <20190205212829.GA20127@alvherre.pgsql>
References: <20190205212829.GA20127@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Tue, 05 Feb 2019 18:28:29 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4571.1549404528.1@sss.pgh.pa.us>
Date: Tue, 05 Feb 2019 17:08:48 -0500
Message-ID: <4572.1549404528@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Jan-29, Tom Lane wrote:
>> It strikes me however that we can stick with the existing catalog contents
>> by making this definition: of the INTERNAL_AUTO dependencies of a given
>> object, the "true owner" to be reported in errors is the dependency
>> that is of the same classId as that object.  If this doesn't uniquely
>> identify one dependency, the report will mention a random one.  This is
>> ugly as well, but it's certainly a lot more practical to cram into v11,
>> and it seems like it would cover the current and likely future use-cases
>> for partition-related objects.  When and if we find a use-case for which
>> this doesn't work, we can think about extending the catalog representation
>> to identify a unique owner in a less ad-hoc way.

> This seems a great idea.  Do you want me to implement it?

I've got much of the code for it already (in the wreckage of my failed
attempts), so I'll go back and finish that up.  I was just waiting to see
how loudly people would howl about using object type as a condition for
figuring out what a pg_depend entry really means.  If we're okay with
that hack, I think I can make it work.

			regards, tom lane