From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Neil Chen <carpenter.nail.cz@gmail.com>
Cc: Alexander Law <exclusion@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Cc: Paul A Jungwirth <pj@illuminatedcomputing.com>
Subject: Re: BUG #17066: Cache lookup failed when null (unknown) is passed as anycompatiblemultirange
Date: Wed, 21 Jul 2021 11:03:51 -0400
Message-ID: <703769.1626879831@sss.pgh.pa.us> (raw)
In-Reply-To: <CAPpHfdtgd42dTehaiPqqP7v978oGSFHjLo_3=D_=UWzFTSwOrg@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>
Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Wed, Jul 21, 2021 at 12:54 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Alexander Korotkov <aekorotkov@gmail.com> writes:
>>> Do I understand correctly that enforce_generic_type_consistency() is
>>> called only after check_generic_type_consistency() returned true?
>>> If so, that means some of the checks are redundant. Therefore, we can
>>> replace ereport()'s with Assert()'s.
>> They are not redundant, IIRC. I forget the exact mechanism for
>> reaching them, but it likely has something to do with aggregates
>> or variadic functions.
> If checks aren't redundant, there should be cases when they don't
> pass. It would be nice to identify these cases and add them to the
> regression tests. I didn't manage to do this yet.
Hmm ... whether or not there are edge cases where those errors are
reachable, it's certainly true that the mainline case doesn't reach
them:
regression=# create function myadd(anyelement, anyelement) returns anyelement
as 'select $1 + $2' language sql;
CREATE FUNCTION
regression=# select myadd(1, 2.3);
ERROR: function myadd(integer, numeric) does not exist
LINE 1: select myadd(1, 2.3);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
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.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, aekorotkov@gmail.com, alvherre@2ndquadrant.com, carpenter.nail.cz@gmail.com, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, pj@illuminatedcomputing.com
Subject: Re: BUG #17066: Cache lookup failed when null (unknown) is passed as anycompatiblemultirange
In-Reply-To: <703769.1626879831@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox