public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Pavel Stehule <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: dynamic result sets support in extended query protocol
Date: Tue, 15 Nov 2022 15:58:57 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAFj8pRCA2XS4Zcs1fbFNQ2WQmVyOhcTzrvEvW+c_kBioDDWpSw@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CALDaNm3VjrBP5-zRyasDC35B+NZD39=c-AZo0=6iDiNu31d3Pg@mail.gmail.com>
<[email protected]>
<CALNJ-vTHehDOEUTD6iBxaLhQAYvLDOrTRn0vVW+wVscy-VtUiQ@mail.gmail.com>
<20220112102055.fn5gpnt2lw6ii35o@jrouhaud>
<[email protected]>
<[email protected]>
<CAFj8pRCA2XS4Zcs1fbFNQ2WQmVyOhcTzrvEvW+c_kBioDDWpSw@mail.gmail.com>
On 14.10.22 19:22, Pavel Stehule wrote:
> 1. there can be possibility to set "dynamic result sets" to unknown. The
> behaviour of the "dynamic result sets" option is a little bit confusing.
> I expect the number of result sets should be exactly the same as this
> number. But the warning is raised only when this number is acrossed. For
> this implementation the correct name should be like "max dynamic result
> sets" or some like this. At this moment, I see this feature "dynamic
> result sets" more confusing, and because the effect is just a warning,
> then I don't see a strong benefit. I can see some benefit if I can
> declare so CALL will be without dynamic result sets, or with exact
> number of dynamic result sets or with unknown number of dynamic result
> sets. And if the result is not expected, then an exception should be
> raised (not warning).
All of this is specified by the SQL standard. (What I mean by that is
that if we want to deviate from that, we should have strong reasons
beyond "it seems a bit odd".)
> 2. Unfortunately, it doesn't work nicely with pagers. It starts a pager
> for one result, and waits for the end, and starts pager for the second
> result, and waits for the end. There is not a possibility to see all
> results at one time. The current behavior is correct, but I don't think
> it is user friendly. I think I can teach pspg to support multiple
> documents. But I need a more robust protocol and some separators -
> minimally an empty line (but some ascii control char can be safer). As
> second step we can introduce new psql option like PSQL_MULTI_PAGER, that
> can be used when possible result sets is higher than 1
I think that is unrelated to this patch. Multiple result sets already
exist and libpq and psql handle them. This patch introduces another way
in which multiple result sets can be produced on the server, but it
doesn't touch the client side. So your concerns should be added either
as a new feature or possibly as a bug against existing psql functionality.
view thread (33+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: dynamic result sets support in extended query protocol
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox