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> <1566947.1754576491@sss.pgh.pa.us>
In-Reply-To: <1566947.1754576491@sss.pgh.pa.us>
From: Dominique Devienne <ddevienne@gmail.com>
Date: Thu, 7 Aug 2025 16:26:34 +0200
Message-ID: <CAFCRh-_zu2hQpACVQaxGiuCFe5FWnEWQCb6TRCa-zfC539mF0g@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-_zu2hQpACVQaxGiuCFe5FWnEWQCb6TRCa-zfC539mF0g%40mail.gmail.com>
Precedence: bulk

On Thu, Aug 7, 2025 at 4:21=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The message presumably was like
>
> ERROR:  procedure ... does not exist
> HINT:  No procedure matches the given name and argument types. You might =
need to add explicit type casts.

Hi Tom.

Indeed it was. I shared my psql session showing that.

> That HINT hasn't been updated since we added named arguments, but
> "argument names don't match" is now also a possible failure reason.
> The simplest possible change would be, say,
>
> HINT:  No procedure matches the given name and argument names/types. You =
might need to add explicit type casts.
>
> Not sure if that's good enough, but the matching rules are
> complex enough that it'd be hard to be definitive about
> the argument name being the problem.

That's better than nothing. And I get it's likely complex.

But still, arg names are not part of the signature.
So they should be checked after the fact.

In my case, the SCHEMA eas explicit, so no search_path.
With the ::name cast, the signature was an exact match.
And there are no overloads at all.

So it's possibly the "worse case" for saying the proc does NOT exist...
It's like the code should do a LEFT JOIN instead of a JOIN on arg names :).

--DD