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
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 |