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.
