From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
cc: Michael Paquier <michael@paquier.xyz>,
 Julien Rouhaud <rjuju123@gmail.com>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Ash M <makmarath@hotmail.com>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #15572: Misleading message reported by "Drop function
 operation" on DB with functions having same name
In-reply-to: 
 <CAKJS1f-ABpt_oT1dL6rSvBch7-u-9+qBLb1KGrhTvDiHZ37e2Q@mail.gmail.com>
References: 
 <CAKJS1f9bAsZVodugqwAS6kSEtrOQKOEpdeBVJALR8iEZf9kHXg@mail.gmail.com>
 <20190212030927.GF1475@paquier.xyz>
 <CAKJS1f9=CdJotJBvjoQfNipPjaVXdDLN1+K-07QFehTGOYH+_g@mail.gmail.com>
 <7757.1550442703@sss.pgh.pa.us>
 <CAOBaU_bPFBb=BA8Askv+1yvcrCFE0-zk3R8XwgbHTY4bhfy1fg@mail.gmail.com>
 <32561.1550594759@sss.pgh.pa.us>
 <CAOBaU_bzP+8nmSaidDtkVBji8hxuXKwGHxjJ7yPRCYD4r-Sovw@mail.gmail.com>
 <CAKJS1f9wOa1CdgFm27NusPZODnL9SkJzxyNuq88VywPj9gS3vg@mail.gmail.com>
 <CAOBaU_Z1Sbd1ZtAjex59PFRKFqcZmJ8sy7s_mqX0T227kZ1Fkg@mail.gmail.com>
 <CAKJS1f-N9NC7K41fRwgRyHEUiBbOLB_Lmhsfu8AnHt2=ZkqBoQ@mail.gmail.com>
 <20190220055627.GH15532@paquier.xyz>
 <CAKJS1f-ABpt_oT1dL6rSvBch7-u-9+qBLb1KGrhTvDiHZ37e2Q@mail.gmail.com>
Comments: In-reply-to David Rowley <david.rowley@2ndquadrant.com>
	message dated "Wed, 20 Feb 2019 21:34:15 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28203.1550694999.1@sss.pgh.pa.us>
Date: Wed, 20 Feb 2019 15:36:39 -0500
Message-ID: <28204.1550694999@sss.pgh.pa.us>
Precedence: bulk

David Rowley <david.rowley@2ndquadrant.com> writes:
> On Wed, 20 Feb 2019 at 18:56, Michael Paquier <michael@paquier.xyz> wrote:
>> I think that the right call is to add the object type into the
>> arguments of LookupFuncName().

I'm not clear how that helps exactly?

> But there are plenty of callers that use LookupFuncName() directly. Do
> you happen to know it's okay for all those to error out with the
> additional error conditions that such a change would move into that
> function?  I certainly don't know that.

The real problem here is that you've unilaterally decided that all callers
of get_object_address() need a particular behavior --- and not only that,
but a behavior that seems fairly surprising and unprincipled, given that
get_object_address's option is documented as "missing_ok" (something the
patch doesn't even bother to change).  It's not very apparent to me why
function-related lookups should start behaving differently from other
lookups in that function, and it's sure not apparent that all callers of
get_object_address() are on board with it.

Should we be propagating that 3-way flag further up, to
get_object_address() callers?  I dunno.

			regards, tom lane