Re: Identifying function-lookup failures due to argument name mismatches - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Identifying function-lookup failures due to argument name mismatches
Date
Msg-id 1459785.1755797452@sss.pgh.pa.us
Whole thread Raw
In response to Re: Identifying function-lookup failures due to argument name mismatches  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
Chao Li <li.evan.chao@gmail.com> writes:
> On Aug 8, 2025, at 09:29, Tom Lane <tgl@sss.pgh.pa.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
rightdirection 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



pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Don't treat virtual generated columns as missing statistics in vacuumdb --missing-stats-only
Next
From: Peter Eisentraut
Date:
Subject: Re: pgaio_io_get_id() type (was Re: Datum as struct)