Re: CALL and named parameters
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Dominique Devienne <ddevienne@gmail.com>, "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Date: 2025-08-07T14:16:25Z
Lists: pgsql-general
Hi
čt 7. 8. 2025 v 15:30 odesílatel David G. Johnston <
david.g.johnston@gmail.com> napsal:
> On Thursday, August 7, 2025, Dominique Devienne <ddevienne@gmail.com>
> wrote:
>>
>>
>> What's not nice is in the way it failed IMHO. I guess I persist it's
>> not a user friendly message :)
>
>
> Then write the error message you would have liked to see.
>
>
>>
>> Can you overload a function solely by changing an argument name?
>
>
> No, the signature is only the name and input argument types.
>
>
>> If not, as I suspect, then function lookup doesn't strictly depend on
>> argument names (like in C++).
>> So the function did exist, with the correct "signature" (ignoring
>> argument names).
>> And I was "just" using the wrong arg-name. That tripped me up.
>
>
> How is it “just” an argument name when you are using named argument syntax?
>
> David J.
>
>
(2025-08-07 15:58:24) postgres=# select fx(b=>10);
ERROR: function fx(b => integer) does not exist
LINE 1: select fx(b=>10);
^
HINT: No function matches the given name and argument types. You might
need to add explicit type casts.
The error message and hint is simillary unfriendly like for a case with
unnamed parameters. I am afraid that implementing a more friendly error
message can slow down the query execution :-/. Now we raise errors when we
know, so we didn't find a good signature, but we don't know what is wrong,
so it is difficult to raise errors in the sense that the name of the
argument is wrong.
Regards
Pavel