Re: CALL and named parameters
| От | Pavel Stehule |
|---|---|
| Тема | Re: CALL and named parameters |
| Дата | |
| Msg-id | CAFj8pRDzBnmztqJY9Zf-DKfK5WYwYzs94R83=w3FjqD1MDvLXQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: CALL and named parameters ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Список | 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.
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
В списке pgsql-general по дате отправления: