Re: BUG #17066: Cache lookup failed when null (iso-8859-1) is passed as anycompatiblemultirange

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17066: Cache lookup failed when null (iso-8859-1) is passed as anycompatiblemultirange
Дата
Msg-id 703769.1626879831@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17066: Cache lookup failed when null (iso-8859-1) is passed as anycompatiblemultirange  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: BUG #17066: Cache lookup failed when null (iso-8859-1) is passed as anycompatiblemultirange  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-bugs
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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Pawel Kudzia
Дата:
Сообщение: Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
Следующее
От: Andres Freund
Дата:
Сообщение: Re: BUG #16696: Backend crash in llvmjit