On Wed, Jul 21, 2021 at 6:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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.
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.
------
Regards,
Alexander Korotkov