Re: Returning multiple result sets

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Returning multiple result sets
Date: 2005-11-20 20:41:36
Message-ID: 19517.1132519296@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Sun, Nov 20, 2005 at 11:29:39AM -0500, Tom Lane wrote:
>> That only works if the caller is prepared to read each result serially,
>> and not (say) a row at a time in parallel.

> Urk! I don't think anyone is suggesting that resultsets can be
> interleaved.

No? If not, why not? The main reason why this is being pushed, IIRC,
is the claim that "you can do this easily in other databases". If you
don't want to support interleaved retrieval of multiple datasets, you
had better be prepared to prove that no other popular database can
do it either.

>> A more realistic way of dealing with multiple resultsets is to deliver
>> them as named cursor references and allow the client to FETCH
>> reasonable-sized chunks. We can sort of handle this today, but it's
>> notationally painful at both the stored-procedure and client ends.

> But if you run a function, it can only return a single row at a time.

This is not about what we can do today with PG functions; it's about
what can be done with a stored procedure in other RDBMSes.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Fuhr 2005-11-20 20:51:11 Plan chosen for PQexecParams
Previous Message Heikki Linnakangas 2005-11-20 20:39:49 Data directory on read-only media