Re: Identifying function-lookup failures due to argument name mismatches
От | Tom Lane |
---|---|
Тема | Re: Identifying function-lookup failures due to argument name mismatches |
Дата | |
Msg-id | 1459785.1755797452@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Identifying function-lookup failures due to argument name mismatches (Chao Li <li.evan.chao@gmail.com>) |
Список | 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 по дате отправления: