Martijn van Oosterhout <kleptog@svana.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