MIME-Version: 1.0
References: <CAFCRh-_iLoUtMAtyunw_-O6sgpWo04sOmB38MUVNpuQVSkL_0Q@mail.gmail.com>
 <CAFj8pRCyW4E5OnZDGvk_YnPqaS_PfK-VKJOKGndC-gtAtDOtBw@mail.gmail.com>
In-Reply-To: <CAFj8pRCyW4E5OnZDGvk_YnPqaS_PfK-VKJOKGndC-gtAtDOtBw@mail.gmail.com>
From: Dominique Devienne <ddevienne@gmail.com>
Date: Thu, 7 Aug 2025 14:44:51 +0200
Message-ID: <CAFCRh-9XkFS==OwSB6jgY84L5d4PkV_Y9MxLgk=NVx0Z8W3o_A@mail.gmail.com>
Subject: Re: CALL and named parameters
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: 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-9XkFS%3D%3DOwSB6jgY84L5d4PkV_Y9MxLgk%3DNVx0Z8W3o_A%40mail.gmail.com>
Precedence: bulk

On Wed, Aug 6, 2025 at 8:09=E2=80=AFPM Pavel Stehule <pavel.stehule@gmail.c=
om> wrote:
> Maybe there is another issue?

Indeed. Thanks Pavel, Andrian, Christoph, for demonstrating I was wrong.
I misinterpreted the signals I got, and accepted the AI's interpretation on
success (after a long day) when the inderlying isse was elsewhere.

My mistake was in
> I verify the names of the parameters, in my CALL with named arguments. OK=
.

I verified against the embedded PL/pgSQL in my code, not what was in the DB=
.
I had renamed an argument in the code, but the schema was instantiated
using the earlier code.
And because I was using the named-argument syntax, but a wrong
arg-name, it fails.

What's not nice is in the way it failed IMHO. I guess I persist it's
not a user friendly message :)

Can you overload a function solely by changing an argument name?
If not, as I suspect, then function lookup doesn't strictly depend on
argument names (like in C++).
So the function did exist, with the correct "signature" (ignoring
argument names).
And I was "just" using the wrong arg-name. That tripped me up.

The AI's suggestion, to go positional, while based on crap reasoning,
did help me, in a way :).

So mea culpa. Apologies for the misguided rant (and smaller re-rant above :=
)).

PS: below's my psql session that led me to the wrong conclusion.

dd_v185=3D> call "Epos-DBA".db_grant_connect_to(grantee_role =3D> 'dd_joe')=
;
ERROR:  procedure Epos-DBA.db_grant_connect_to(grantee_role =3D>
unknown) does not exist
LINE 1: call "Epos-DBA".db_grant_connect_to(grantee_role =3D> 'dd_joe'...
             ^
HINT:  No procedure matches the given name and argument types. You
might need to add explicit type casts.
dd_v185=3D> call "Epos-DBA".db_grant_connect_to(grantee_role =3D> 'dd_joe':=
:name);
ERROR:  procedure Epos-DBA.db_grant_connect_to(grantee_role =3D> name)
does not exist
LINE 1: call "Epos-DBA".db_grant_connect_to(grantee_role =3D> 'dd_joe'...
             ^
HINT:  No procedure matches the given name and argument types. You
might need to add explicit type casts.
dd_v185=3D> \df "Epos-DBA".db_grant_connect_to
                               List of functions
  Schema  |        Name         | Result data type | Argument data types | =
Type
----------+---------------------+------------------+---------------------+-=
-----
 Epos-DBA | db_grant_connect_to |                  | IN login_role name  | =
proc
(1 row)

dd_v185=3D> select has_schema_privilege('Epos-DBA', 'usage');
 has_schema_privilege
----------------------
 t
(1 row)

dd_v185=3D> select
has_function_privilege('"Epos-DBA".db_grant_connect_to(name)',
'execute');
 has_function_privilege
------------------------
 t
(1 row)

dd_v185=3D> call "Epos-DBA".db_grant_connect_to('dd_joe');
CALL