Re: BUG #17066: Cache lookup failed when null (unknown) is passed as anycompatiblemultirange

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com>, Alexander Law <exclusion(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Subject: Re: BUG #17066: Cache lookup failed when null (unknown) is passed as anycompatiblemultirange
Date: 2021-07-21 15:03:51
Message-ID: 703769.1626879831@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> On Wed, Jul 21, 2021 at 12:54 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alexander Korotkov <aekorotkov(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2021-07-21 16:59:27 Re: BUG #16696: Backend crash in llvmjit
Previous Message Pawel Kudzia 2021-07-21 10:49:57 Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows