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

On Tue, Jul 27, 2021 at 10:43 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> > On Wed, Jul 21, 2021 at 6:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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.
>
> > I spend some time thinking about this. I'm actually not sure this
> > approach is really correct. If there is only one polymorphic
> > candidate, it's still possible that the user means non-polymorphic
> > function with exactly matching arguments, which is simply doesn't
> > exist.
>
> I don't particularly buy that reasoning. Certainly the true cause of
> the error could be that the user mistyped the function name, or meant
> to refer to something that's not in the search_path, or forgot to load
> the function into this particular database, etc etc. But we have
> to act on the basis of the information we have, and that is the
> function(s) we see. If we let possibilities like these paralyze us,
> we'll never be able to issue useful error messages at all.
>
> I don't deny that what I'm proposing above is a bit weird and
> non-orthogonal; there may be a better way to do it. But the
> existing code structure where check_generic_type_consistency
> silently returns a boolean just isn't very conducive to giving
> a good error message. We have a lot more information available
> to give, if we choose to give it.
>
> Possibly we should think in terms of rewriting
> enforce_generic_type_consistency's messages so that they are
> errdetail() messages with a common primary message that's still
> some variation of "there's no matching function".

That's an interesting idea! If the primary message is still "there's
no matching function", I feel absolutely comfortable about putting
information about "closest match" into detail.

------
Regards,
Alexander Korotkov