From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Neil Chen <carpenter.nail.cz@gmail.com>,
        Alexander Law <exclusion@gmail.com>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
        Paul A Jungwirth <pj@illuminatedcomputing.com>
Subject: Re: BUG #17066: Cache lookup failed when null (unknown) is passed as
 anycompatiblemultirange
In-reply-to: 
 <CAPpHfdvaA3DHeAkVkjfVEu9BXtwApxAj9y_RGqtDeam-gOy2tg@mail.gmail.com>
References: 
 <CAA3qoJ=gMC8Uvz1VoO3BUoPCTByBmoJ8aXzLGQoK3RseyqcdCQ@mail.gmail.com>
 <202106221342.lab2x5tvhcbs@alvherre.pgsql>
 <CAPpHfdtT+Nq+ERXBku-XsVvsqS+amrt__bogy1WSnxhZPCJOcA@mail.gmail.com>
 <CAPpHfdtT8NJGcBzx6OnDxMOrp0BjPsFjCLrL82xqFa4639R7Nw@mail.gmail.com>
 <CAPpHfduRX=mft=30bcTmzPKm859Pjwpqk7TTkEy-6GddUxTpFA@mail.gmail.com>
 <CAPpHfdu4MhM_rrdGf6uZN9uh2=9ay-a2s=bpVzG_BoTSD4RU_w@mail.gmail.com>
 <2549561.1624491310@sss.pgh.pa.us>
 <CAPpHfduOx3UgF1fmThMj8XrgDhsxxE1DWAF4oR6z2EeVJ+PVtQ@mail.gmail.com>
 <640279.1626818095@sss.pgh.pa.us>
 <CAPpHfdtgd42dTehaiPqqP7v978oGSFHjLo_3=D_=UWzFTSwOrg@mail.gmail.com>
 <703769.1626879831@sss.pgh.pa.us>
 <CAPpHfdvaA3DHeAkVkjfVEu9BXtwApxAj9y_RGqtDeam-gOy2tg@mail.gmail.com>
Comments: In-reply-to Alexander Korotkov <aekorotkov@gmail.com>
	message dated "Tue, 27 Jul 2021 18:31:05 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <455833.1627415032.1@sss.pgh.pa.us>
Date: Tue, 27 Jul 2021 15:43:52 -0400
Message-ID: <455834.1627415032@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/455834.1627415032%40sss.pgh.pa.us>
Precedence: bulk

Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Wed, Jul 21, 2021 at 6:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That's too bad, because IMO it'd be way more helpful to say
>> ERROR:  arguments declared "anyelement" are not all alike
>> DETAIL:  integer versus numeric
>> which is what enforce_generic_type_consistency would say if it
>> were reached.  Similarly, the other error cases in that code
>> are far more specific and thus more helpful than simply reporting
>> that there's no matching function.
>> 
>> I'm tempted to propose that, if there is only one possible match
>> but check_generic_type_consistency rejects it, then
>> function/operator lookup should return that OID anyway, allowing
>> enforce_generic_type_consistency to throw the appropriate error.
>> This would obviously not help when there are multiple polymorphic
>> functions having the same name and number of arguments, but that
>> strikes me as a very unusual corner case.

> I spend some time thinking about this.  I'm actually not sure this
> approach is really correct.  If there is only one polymorphic
> candidate, it's still possible that the user means non-polymorphic
> function with exactly matching arguments, which is simply doesn't
> exist.

I don't particularly buy that reasoning.  Certainly the true cause of
the error could be that the user mistyped the function name, or meant
to refer to something that's not in the search_path, or forgot to load
the function into this particular database, etc etc.  But we have
to act on the basis of the information we have, and that is the
function(s) we see.  If we let possibilities like these paralyze us,
we'll never be able to issue useful error messages at all.

I don't deny that what I'm proposing above is a bit weird and
non-orthogonal; there may be a better way to do it.  But the
existing code structure where check_generic_type_consistency
silently returns a boolean just isn't very conducive to giving
a good error message.  We have a lot more information available
to give, if we choose to give it.

Possibly we should think in terms of rewriting
enforce_generic_type_consistency's messages so that they are
errdetail() messages with a common primary message that's still
some variation of "there's no matching function".

			regards, tom lane