[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [GENERAL] Full Stored Procedure Support, any time soon ?
From:       Thomas Kellerer <spam_eater () gmx ! net>
Date:       2013-11-30 23:27:35
Message-ID: l7ds8t$aar$1 () ger ! gmane ! org
[Download RAW message or body]

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 one result 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)





-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[prev in list] [next in list] [prev in thread] [next in thread]