Re: Identifying function-lookup failures due to argument name mismatches

> On Aug 25, 2025, at 02:47, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Here is a v4 with some additional bike-shedding on the error texts.
> In particular, I decided that it was worth expending an additional
> flag bit so that we could reliably distinguish "There is no function
> of that name" from "A function of that name exists, but it is not in
> the search_path". (Since FuncnameGetCandidates is already searching
> the entire set of functions matching the given name, it doesn't take
> any extra work to know that there's a match outside the search path.)
> I rephrased a couple of the other messages too, but without any
> substantive logic change.
>

I tested various error cases, all got proper error messages. So, I think this patch has significantly improved the situation.

I just have a tiny comment. In func_lookup_failure_details(), there are a lot of duplicate code like:

```
if (proc_call)
return errdetail("A procedure of that name exists, but it is not in the search_path.");
else
return errdetail("A function of that name exists, but it is not in the search_path.”);
```

The if-else is just to distinguish “procedure” and “function”, rest of words are duplicated.

Can we avoid the duplication in a way like:

```
static int
func_lookup_failure_details(int fgc_flags, List *argnames, bool proc_call)
{
const char *func_kind = proc_call ? "procedure" : "function";

/*
if (proc_call)
return errdetail("There is no procedure of that name.");
else
return errdetail("There is no function of that name.");
*/
return errdetail("There is no %s of that name.", func_kind);
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/