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
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) |