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

I wrote:
> Dunno, I think the new messages already cover all the interesting
> cases of argument name mismatch. I'm hesitant to touch the
> longstanding hint, and if I did I'd probably change it more than that,
> to something like

> ERROR: function foo(integer) does not exist
> DETAIL: No function of that name matches the given argument types.
> HINT: You might need to add explicit type casts.

> because whoever wrote it originally had a poor grasp of our
> error message style guide. But that'd result in very widespread
> changes in our regression test outputs, probably likewise break
> the regression tests of extensions and other downstream code,
> and generally cause a lot more pain than I think it's worth.
> (Maybe others think differently?)

I decided to investigate just how bad changing this would be, and it
seems maybe not *that* awful. v3-0001 attached is much like v2-0001,
and then 0002 shows the effects of changing the wording of this hint,
and 0003 and 0004 explore cleaning up some related messages. I count
the following numbers of changed messages in each patch:

$ grep '^-HINT' v3-0001-Provide-more-specific-error-hints-for-function-lo.patch | wc
17 306 1803
$ grep '^-HINT' v3-0002-Change-the-wording-of-our-traditional-function-no.patch | wc
40 715 4214
$ grep '^-HINT' v3-0003-Improve-the-messages-for-operator-not-found-too.patch | wc
19 342 2014
$ grep '^-HINT' v3-0004-Mop-up-a-few-other-error-message-style-violations.patch | wc
7 109 644

So doing all of this is certainly a little bit invasive, but it's not
out of the question IMO. On the other hand it could certainly be
argued that 0002-0004 are just style nannyism.

0001 makes a couple of changes compared to v2. I adopted your thought
of passing back a flag bit about a schema name being given after all.
I concluded that was a bit cleaner than the other way. I still think
it's best for ParseFuncOrColumn to uniformly use "argnames != NIL"
for checking whether there are argnames, though. Also, I added a
flag bit and error message for the case where none of the candidate
functions have the right number of arguments, because when that's
true, we'll never get to looking at argument names or types. And
I switched some of the messages from HINT to DETAIL.

regards, tom lane