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

Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
> I like the new messages in func_lookup_failure_details(). Very much
> so in fact. BUT I still don't like the fallback "traditional"
> message, because the way I read it, it fails to mention argument
> *names* could be the reason for the lookup failure. Now maybe that's
> moot, because of earlier messages. But I can't know that myself, thus
> I'm still re-iterating my feeling on this. In my reading, "given
> name" applies to "function" or "procedure" before it, and not to
> "argument" after it. Thus I'd go with "and argument types or names".

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?)

Perhaps a compromise could be to use two different hint messages,
mentioning argument names only when the call actually used some.
That would limit the blast radius a good deal, I think, though
I didn't try counting affected tests.

> One thing I find missing are flags about the actual syntax used by the
> user, i.e.
> is it schema-qualified?
> does it use named arguments?

I thought that wasn't really necessary, because the caller already
knows those things, or can discover them about as easily as by
checking a flag.

> If some flags you've added Tom, are TRUE, then that's implied.
> But is the converse true? i.e. if the flag is FALSE, can you know
> whether named-args were used? (schema-qualified seems special, as
> fails earlier, if I read you right). Because it could have some
> bearing on the errors, no?

The patch's func_lookup_failure_details() code shows how I intended
to deal with those questions. Sure, we could also do that through
returned flags, but is that better? ParseFuncOrColumn contains
existing tests for "argnames != NIL", so checking that the same way
in this new code seemed better than doing it differently.

regards, tom lane