From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Returning multiple result sets |
Date: | 2005-11-20 14:07:23 |
Message-ID: | 20051120140717.GA32031@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Nov 19, 2005 at 08:02:08PM -0300, Alvaro Herrera wrote:
> Hmm -- probably we could declare that the current libpq API will not
> support multiple result sets from one query, and return only the first
> one to the application discarding the rest. (It just occured to me --
> what happens if one send multiple SELECTs in a semicolon-separated query
> via libpq?). New apps wanting to take advantage of the new
> functionality would need to invoke a different function.
libpq supports it just fine. You do a PQsendQuery() and then as many
PQgetResult()s as it takes to get back the results. This worked for a
while AFAIK.
> At the protocol level this will need an extension anyway, so clients
> using the protocol directly would need to be updated to understand
> multiple results.
The protocol supports it fine. If the server sends a new 'T' record,
libpq assumes it's returning a new resultset. When the server sends a
"ready for query" message, libpq knows that the last resultset has
arrived.
It's the backend that needs work, not the protocol.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-11-20 14:09:25 | Re: Returning multiple result sets |
Previous Message | Simon Riggs | 2005-11-20 11:04:59 | Re: Virtual tuple slots versus TOAST: big problem |