From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Dominique Devienne <ddevienne(at)gmail(dot)com> |
Subject: | Re: Identifying function-lookup failures due to argument name mismatches |
Date: | 2025-08-21 17:30:52 |
Message-ID: | 1459785.1755797452@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> writes:
> On Aug 8, 2025, at 09:29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I couldn't quite let go of this, and after some thought I hit on the
>> idea of making FuncnameGetCandidates pass back a bitmask of flags
>> showing how far the match succeeded.
> I traced this problem today, and I agree that making FuncnameGetCandidates to pass out some information should be right direction to go.
> When there are multiple matches, I think we can find the best match by considering argument names/types, default values. If there are still multiple best matches, I think we can prompt all matches to client.
I don't want to touch the existing rules about how we winnow down the
potential matches. That has a risk of breaking applications that are
fine today. The idea of this patch is just to give more-specific
error messages when we end up with no matches. (In fact, one of the
points that I think could use review is checking that the small
refactoring I did have to do inside MatchNamedCall didn't change
its existing outputs.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-08-21 17:56:23 | Re: pgaio_io_get_id() type (was Re: Datum as struct) |
Previous Message | Yugo Nagata | 2025-08-21 17:23:54 | Re: Don't treat virtual generated columns as missing statistics in vacuumdb --missing-stats-only |