Re: CALL and named parameters

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.

regards, tom lane