Re: Identifying function-lookup failures due to argument name mismatches
От | Dominique Devienne |
---|---|
Тема | Re: Identifying function-lookup failures due to argument name mismatches |
Дата | |
Msg-id | CAFCRh-9Gr_bLXNY53jY-9uDHVttBuKGxvd3CtgErbM3XZE673A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Identifying function-lookup failures due to argument name mismatches (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Identifying function-lookup failures due to argument name mismatches
|
Список | pgsql-hackers |
On Fri, Aug 22, 2025 at 12:58 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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 [...] it seems maybe not *that* awful. Great. > 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. Excellent. Thanks for sharing. Maybe I'll get another undeserved medallion then :) > it's best for ParseFuncOrColumn to uniformly use "argnames != NIL" > for checking whether there are argnames, though. I'm sure you're right. But given the above, an out flag for it too would be more consistent, like the schema one. My $0.02. > Also, I added a flag bit [...] where none of the candidate [...] > because when that's true, we'll never get to looking at arguments Sounds like an improvement indeed. Subtle difference I didn't even get on my first reading of your mail. You're into it now! One last though. Is it worth reserving a few bits to count the candidate matches? You'll never reach 32 flags, so 8 feels like plenty. Barring listing the candidates, a count hint might help? In my case it was only 1, but it more complete cases where the search_path is involved, one might get surprised with candidates coming from afar making things ambiguous? Again, jus thinking aloud. --DD
В списке pgsql-hackers по дате отправления: