Thread: retrieving results of procedures with OUT params

retrieving results of procedures with OUT params

From
PG Doc comments form
Date:
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/libpq-exec.html
Description:

https://www.postgresql.org/docs/16/libpq-exec.html#LIBPQ-PQRESULTSTATUS
Existing text:
If the result status is PGRES_TUPLES_OK, PGRES_SINGLE_TUPLE, or
PGRES_TUPLES_CHUNK, then the functions described below can be used to
retrieve the rows returned by the query. Note that a SELECT command that
happens to retrieve zero rows still shows PGRES_TUPLES_OK. PGRES_COMMAND_OK
is for commands that can never return rows (INSERT or UPDATE without a
RETURNING clause, etc.). A response of PGRES_EMPTY_QUERY might indicate a
bug in the client software.
Add:
A successful call to a procedure with OUT parameters will set
PGRES_TUPLES_OK and return one row with the functions described below.

Re: retrieving results of procedures with OUT params

From
"David G. Johnston"
Date:
On Monday, September 2, 2024, PG Doc comments form <noreply@postgresql.org> wrote:
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/libpq-exec.html
Description:

https://www.postgresql.org/docs/16/libpq-exec.html#LIBPQ-PQRESULTSTATUS
Existing text:
If the result status is PGRES_TUPLES_OK, PGRES_SINGLE_TUPLE, or
PGRES_TUPLES_CHUNK, then the functions described below can be used to
retrieve the rows returned by the query. Note that a SELECT command that
happens to retrieve zero rows still shows PGRES_TUPLES_OK. PGRES_COMMAND_OK
is for commands that can never return rows (INSERT or UPDATE without a
RETURNING clause, etc.). A response of PGRES_EMPTY_QUERY might indicate a
bug in the client software.
Add:
A successful call to a procedure with OUT parameters will set
PGRES_TUPLES_OK and return one row with the functions described below.

Defining whether a given SQL query is or is not going to return tuples is not the responsibility of this paragraph.  The documentation for CALL is where this knowledge is imparted.  I’m not hard set against adding something here but it also doesn’t really seem like a need.

If I were to do something I’d probably add “or a CALL of a procedure lacking OUT parameters, etc” as another example in the parenthetical talking about an omitted returning clause.

David J.

Re: retrieving results of procedures with OUT params

From
"ch.l.ngre"
Date:

Am 07.09.2024 um 18:35 schrieb David G. Johnston:
> On Monday, September 2, 2024, PG Doc comments form
> <noreply@postgresql.org <mailto:noreply@postgresql.org>> wrote:
>
>     The following documentation comment has been logged on the website:
>
>     Page: https://www.postgresql.org/docs/16/libpq-exec.html
>     <https://www.postgresql.org/docs/16/libpq-exec.html>
>     Description:
>
>     https://www.postgresql.org/docs/16/libpq-exec.html#LIBPQ-PQRESULTSTATUS
<https://www.postgresql.org/docs/16/libpq-exec.html#LIBPQ-PQRESULTSTATUS>
>     Existing text:
>     If the result status is PGRES_TUPLES_OK, PGRES_SINGLE_TUPLE, or
>     PGRES_TUPLES_CHUNK, then the functions described below can be used to
>     retrieve the rows returned by the query. Note that a SELECT command that
>     happens to retrieve zero rows still shows PGRES_TUPLES_OK.
>     PGRES_COMMAND_OK
>     is for commands that can never return rows (INSERT or UPDATE without a
>     RETURNING clause, etc.). A response of PGRES_EMPTY_QUERY might
>     indicate a
>     bug in the client software.
>     Add:
>     A successful call to a procedure with OUT parameters will set
>     PGRES_TUPLES_OK and return one row with the functions described below.
>
>
> Defining whether a given SQL query is or is not going to return tuples
> is not the responsibility of this paragraph.  The documentation for CALL
> is where this knowledge is imparted.  I’m not hard set against adding
> something here but it also doesn’t really seem like a need.
>
> If I were to do something I’d probably add “or a CALL of a procedure
> lacking OUT parameters, etc” as another example in the parenthetical
> talking about an omitted returning clause.
>
> David J.
>

You are right, the documentation for CALL states that a row is being
returned.
However if you read
https://www.postgresql.org/docs/current/xproc.html#XPROC
'Procedures do not return a function value; hence CREATE PROCEDURE lacks
a RETURNS clause. However, procedures can instead return data to their
callers via output parameters'
this does not sound like a row being returned. Also plpgsql does not do
it when you invoke CALL.
The libpq documentation does not mention CALL of a stored procedure with
out params at all. Maybe it should, - somewhere.

Christoph



Re: retrieving results of procedures with OUT params

From
"David G. Johnston"
Date:


On Sat, Sep 7, 2024, 11:56 ch.l.ngre <ch.l.ngre@online.de> wrote:



You are right, the documentation for CALL states that a row is being
returned.
However if you read
https://www.postgresql.org/docs/current/xproc.html#XPROC
'Procedures do not return a function value; hence CREATE PROCEDURE lacks
a RETURNS clause. However, procedures can instead return data to their
callers via output parameters'
this does not sound like a row being returned.

Correct, because from the perspective of the procedure all it is aware of is it's output arguments.  The caller is either SQL CALL or plpgsql (or someone else) which deal with those outputs differently.

Also plpgsql does not do
it when you invoke CALL.
The libpq documentation does not mention CALL of a stored procedure with
out params at all. Maybe it should, - somewhere.

It's better from a pure separation of concerns if libpq has no awareness that CALL was the command only seeing that whatever the SQL a tuple exists on the wire to be processed.

That is the crux of the hesitation here, you are breaking encapsulation/isolation of concerns.  Libpq has little need or desire to be aware of the specific SQL commands being passed around.  It is a client-server message passing protocol.

David J.