MIME-Version: 1.0
References: <CAFCRh-_iLoUtMAtyunw_-O6sgpWo04sOmB38MUVNpuQVSkL_0Q@mail.gmail.com>
 <CAFj8pRCyW4E5OnZDGvk_YnPqaS_PfK-VKJOKGndC-gtAtDOtBw@mail.gmail.com>
 <CAFCRh-9XkFS==OwSB6jgY84L5d4PkV_Y9MxLgk=NVx0Z8W3o_A@mail.gmail.com>
 <CAKFQuwaGO-pmBVc2Vk9vwmbkhNpxHeZM77=oCtG+Duoc-G58cg@mail.gmail.com>
 <CAFCRh-8-sKZS7-xFO=Ku0waTjKfm0qhGVWWKZ9qsgzJEcPK7BA@mail.gmail.com> <1568931.1754577361@sss.pgh.pa.us>
In-Reply-To: <1568931.1754577361@sss.pgh.pa.us>
From: Dominique Devienne <ddevienne@gmail.com>
Date: Thu, 7 Aug 2025 16:39:03 +0200
Message-ID: <CAFCRh-_FCJNJ3hzutzzFkOSc_zs_rrCG90iFtjUbPt32Y6sVHw@mail.gmail.com>
Subject: Re: CALL and named parameters
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, 
	"pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAFCRh-_FCJNJ3hzutzzFkOSc_zs_rrCG90iFtjUbPt32Y6sVHw%40mail.gmail.com>
Precedence: bulk

On Thu, Aug 7, 2025 at 4:36=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dominique Devienne <ddevienne@gmail.com> 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