Re: Identifying function-lookup failures due to argument name mismatches

From: Dominique Devienne <ddevienne(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Identifying function-lookup failures due to argument name mismatches
Date: 2025-08-22 07:52:06
Message-ID: CAFCRh-9Gr_bLXNY53jY-9uDHVttBuKGxvd3CtgErbM3XZE673A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 22, 2025 at 12:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-08-22 08:19:35 Re: SQL:2023 JSON simplified accessor support
Previous Message Olga Antonova 2025-08-22 07:40:49 Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)