Re: CALL and named parameters

On Thu, Aug 7, 2025 at 4:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
> > I was expecting an error telling me the procedure exists, but the
> > argument name used in the call didn't. Then it's obvious to me what
> > mistake I made. If argument names don't participate in the function's
> > signature, why should they participate in the lookup? Do the lookup
> > based on name and arg types (and count), that gives you a possible
> > overload set, which in my second attempt (with a ::name cast) WAS AN
> > EXACT MATCH for the signature, then give me an error about the
> > argument name, that does NOT tell me the function doesn't exist.
> > That's what I would expect.
>
> Criticism in the form of a patch is welcome ;-). The problem here
> is that the matching rules are far more complicated than you seem
> to think. It's not clear to me that we can definitively say that
> "we would have had a match except the argument name was wrong".
> If it is possible to know that, it's quite a few subroutines below
> where the error is actually issued (see ParseFuncOrColumn ->
> func_get_detail -> FuncnameGetCandidates -> MatchNamedCall).
> Maybe there's some fairly painless change that could be made in
> that rat's nest, but I lack enough caffeine to see it.

How about listing those "candidates" considered? In the detailed message?
With arg names. Then it would have been obvious(er), I'm arguing. --DD