From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
Subject: | Identifying function-lookup failures due to argument name mismatches |
Date: | 2025-08-08 01:29:18 |
Message-ID: | 1756041.1754616558@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
We've had various complaints about how our error reports aren't too
helpful if a function lookup failure occurs because you misspell
the name of a named argument. The most recent is at [1], but there
have been others if memory serves.
I took a swing at improving this, as attached. It turns out to be
about as messy as I feared, because the basic question of "did the
argument names match" turns out to be intermixed with a bunch of
random rules about default arguments and precisely how you're allowed
to mix named and positional arguments. So, of the three existing
test cases that this patch changes the results for, the first change
is quite on-point but the second and third maybe not so much.
Perhaps this could be improved further with some refactoring, but the
function lookup logic is complicated and changing it would raise the
odds of introducing a bug quite a lot.
Another thing not to like is that it seems like this is doing violence
to several APIs in exchange for not very much improvement in the error
messages. I feel like maybe we ought to be trying for more
specificity about additional cases, but I'm not very sure what else
to improve or what the API could look like.
Anyway, I'm not seriously proposing that this should be committed
as-is. I'm throwing it out there in case anyone else has a good
idea or feels motivated to push on the problem some more.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v1-improve-function-lookup-failure-errors.patch | text/x-diff | 11.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-08-08 01:34:05 | Re: Backpatching injection point core facilities to REL_17_STABLE |
Previous Message | Michael Paquier | 2025-08-08 00:35:52 | Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring |