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
