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
|
Список | 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 по дате отправления: