Re: CALL and named parameters - Mailing list pgsql-general

From Dominique Devienne
Subject Re: CALL and named parameters
Date
Msg-id CAFCRh-_zu2hQpACVQaxGiuCFe5FWnEWQCb6TRCa-zfC539mF0g@mail.gmail.com
Whole thread Raw
In response to Re: CALL and named parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CALL and named parameters
List pgsql-general
On Thu, Aug 7, 2025 at 4:21 PM 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



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: CALL and named parameters
Next
From: Tom Lane
Date:
Subject: Re: CALL and named parameters