agora inbox for pgsql-docs@postgresql.org
help / color / mirror / Atom feedretrieving results of procedures with OUT params
4+ messages / 3 participants
[nested] [flat]
* retrieving results of procedures with OUT params
@ 2024-09-02 10:16 PG Doc comments form <noreply@postgresql.org>
2024-09-07 16:35 ` Re: retrieving results of procedures with OUT params David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: PG Doc comments form @ 2024-09-02 10:16 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: ch.l.ngre@online.de
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.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: retrieving results of procedures with OUT params
2024-09-02 10:16 retrieving results of procedures with OUT params PG Doc comments form <noreply@postgresql.org>
@ 2024-09-07 16:35 ` David G. Johnston <david.g.johnston@gmail.com>
2024-09-07 18:57 ` Re: retrieving results of procedures with OUT params ch.l.ngre <ch.l.ngre@online.de>
0 siblings, 1 reply; 4+ messages in thread
From: David G. Johnston @ 2024-09-07 16:35 UTC (permalink / raw)
To: ch.l.ngre@online.de <ch.l.ngre@online.de>; pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
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.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: retrieving results of procedures with OUT params
2024-09-02 10:16 retrieving results of procedures with OUT params PG Doc comments form <noreply@postgresql.org>
2024-09-07 16:35 ` Re: retrieving results of procedures with OUT params David G. Johnston <david.g.johnston@gmail.com>
@ 2024-09-07 18:57 ` ch.l.ngre <ch.l.ngre@online.de>
2024-09-07 20:07 ` Re: retrieving results of procedures with OUT params David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: ch.l.ngre @ 2024-09-07 18:57 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: retrieving results of procedures with OUT params
2024-09-02 10:16 retrieving results of procedures with OUT params PG Doc comments form <noreply@postgresql.org>
2024-09-07 16:35 ` Re: retrieving results of procedures with OUT params David G. Johnston <david.g.johnston@gmail.com>
2024-09-07 18:57 ` Re: retrieving results of procedures with OUT params ch.l.ngre <ch.l.ngre@online.de>
@ 2024-09-07 20:07 ` David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 0 replies; 4+ messages in thread
From: David G. Johnston @ 2024-09-07 20:07 UTC (permalink / raw)
To: ch.l.ngre <ch.l.ngre@online.de>; +Cc: PostgreSQL Documentation <pgsql-docs@lists.postgresql.org>
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.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-09-07 20:07 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-09-02 10:16 retrieving results of procedures with OUT params PG Doc comments form <noreply@postgresql.org>
2024-09-07 16:35 ` David G. Johnston <david.g.johnston@gmail.com>
2024-09-07 18:57 ` ch.l.ngre <ch.l.ngre@online.de>
2024-09-07 20:07 ` David G. Johnston <david.g.johnston@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox