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.
