On Thu, Aug 7, 2025 at 4:36 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Dominique Devienne <ddevie...@gmail.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
