public inbox for [email protected]
help / color / mirror / Atom feedRe: CALL and named parameters
2+ messages / 2 participants
[nested] [flat]
* Re: CALL and named parameters
@ 2025-08-07 14:36 Tom Lane <[email protected]>
2025-08-07 14:39 ` Re: CALL and named parameters Dominique Devienne <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Tom Lane @ 2025-08-07 14:36 UTC (permalink / raw)
To: Dominique Devienne <[email protected]>; +Cc: David G. Johnston <[email protected]>; Pavel Stehule <[email protected]>; [email protected] <[email protected]>
Dominique Devienne <[email protected]> writes:
> 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.
Criticism in the form of a patch is welcome ;-). The problem here
is that the matching rules are far more complicated than you seem
to think. It's not clear to me that we can definitively say that
"we would have had a match except the argument name was wrong".
If it is possible to know that, it's quite a few subroutines below
where the error is actually issued (see ParseFuncOrColumn ->
func_get_detail -> FuncnameGetCandidates -> MatchNamedCall).
Maybe there's some fairly painless change that could be made in
that rat's nest, but I lack enough caffeine to see it.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: CALL and named parameters
2025-08-07 14:36 Re: CALL and named parameters Tom Lane <[email protected]>
@ 2025-08-07 14:39 ` Dominique Devienne <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Dominique Devienne @ 2025-08-07 14:39 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; Pavel Stehule <[email protected]>; [email protected] <[email protected]>
On Thu, Aug 7, 2025 at 4:36 PM Tom Lane <[email protected]> wrote:
> Dominique Devienne <[email protected]> writes:
> > 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.
>
> Criticism in the form of a patch is welcome ;-). The problem here
> is that the matching rules are far more complicated than you seem
> to think. It's not clear to me that we can definitively say that
> "we would have had a match except the argument name was wrong".
> If it is possible to know that, it's quite a few subroutines below
> where the error is actually issued (see ParseFuncOrColumn ->
> func_get_detail -> FuncnameGetCandidates -> MatchNamedCall).
> Maybe there's some fairly painless change that could be made in
> that rat's nest, but I lack enough caffeine to see it.
How about listing those "candidates" considered? In the detailed message?
With arg names. Then it would have been obvious(er), I'm arguing. --DD
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-08-07 14:39 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-08-07 14:36 Re: CALL and named parameters Tom Lane <[email protected]>
2025-08-07 14:39 ` Dominique Devienne <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox