Re: CALL and named parameters
От | Dominique Devienne |
---|---|
Тема | Re: CALL and named parameters |
Дата | |
Msg-id | CAFCRh-8-sKZS7-xFO=Ku0waTjKfm0qhGVWWKZ9qsgzJEcPK7BA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: CALL and named parameters ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: CALL and named parameters
|
Список | pgsql-general |
On Thu, Aug 7, 2025 at 3:30 PM David G. Johnston <david.g.johnston@gmail.com> wrote: > On Thursday, August 7, 2025, Dominique Devienne <ddevienne@gmail.com> wrote: >> Can you overload a function solely by changing an argument name? > No, the signature is only the name and input argument types. Thanks for confirming. >> So the function did exist, with the correct "signature". >> 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? I was expecting an error telling me the procedure exists, but the argument name used in the call didn't. Then it's obvious to me what mistake I made. If argument names don't participate in the function's signature, why should they participate in the lookup? Do the lookup based on name and arg types (and count), that gives you a possible overload set, which in my second attempt (with a ::name cast) WAS AN EXACT MATCH for the signature, then give me an error about the argument name, that does NOT tell me the function doesn't exist. That's what I would expect. Now, as a dev, I understand that my own experience is a tiny subcase of a larger problem. I'm sure it can be super complex in the general case. HINT: No procedure matches the given name and argument types. You might need to add explicit type casts. in "given name and argument types", `name` applies to the procedure name? Was how I read it. Or it ALSO applies to types too (wasn't my interpretation). The hint mentions casts, which I tried, to no avail. The hint does NOT mention check the arg-names, especially since it knows I'm using named-arguments at the call side. I'm saying that's a poor user experience. Yes it's my error. I should have known better, yadi yadi yada. When you try to DROP an object with privileges on some objects, it lists you those objects. Here, it doesn't even lists you the candidates from the overload set. With param names, if using named argument. We can agree to disagree. PostgreSQL is OSS and all. I'm just telling you, and the community at large, that this error is misleading IMHO, and that it tripped me up, and I'm making noise in the hope it gets improved, so the next user (probably me!) that runs into it next, has a better chance of not wasting a few hours on that one. Thanks, --DD
В списке pgsql-general по дате отправления: