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 по дате отправления: