John R Pierce wrote on 30.11.2013 23:47:
> On 11/30/2013 2:30 PM, Noel Diaz wrote:
>> This might involve the control of transaction state and the return of multiple result sets
>>
>> * PL/pgSQL stored procedure returning multiple result sets (SELECTs)?
<http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php>
>> * Proposal: real procedures again (8.4) <http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php>
>> * http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php
>> * Gathering specs and discussion on feature (post 9.1)
<http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php>
>>
>> Does anybody know if any the committers are working on that list?
>
> I don't think the libpq API will allow that first one, a SQL query can only return a single recordset
>of rows that all have the same fields.
I don't think that's a limitation. The client will still iterate through one result set at a time.
The "potential" result sets would need to be somehow "prepared to be sent" on the server. When the client has exhausted
oneresult set, it requests the next one (or asks if there _is_ a next one). Only then the server starts streaming the
results.That way libpg would only deal with a single result at a time.
I don't think SQL Server or MySQL actually send all results at once (definitely not when using JDBC)
