Tom Lane wrote: > I'm not really holding my breath for that to happen, considering > it would involve fundamental breakage of the wire protocol. > (For example, extended query protocol assumes that Describe > Portal only needs to describe one result set. There might be > more issues, but that one's bad enough.)
I'm not sure that CALL can be used at all with the extended protocol today (just like multiple queries per statements, except that for these, I'm sure). My interpretation is that the extended protocol deliberately lefts out the possibility of multiple result sets because it doesn't fit with how it's designed and if you want to have this, you can just use the old protocol's Query message. There is no need to break anything or invent anything but on the contrary to use the older way. Considering these 3 ways to use libpq to send queries: 1. using old protocol with PQexec: only one resultset. 2. using old protocol with PQsendQuery+looping on PQgetResult: same as #1 except multiple result sets can be processed 3. using extended protocol: not for multiple result sets, not for copy, possibly not for other things, but can use bind parameters, binary format, pipelining,... The current patch is about using #2 instead of #1. They have been patches about doing bits of #3 in some cases (binary output, maybe parameters too?) and none got eventually in. ISTM that the current situation is that psql is stuck at #1 since forever so it's not fully using the capabilities of the protocol, both old and new. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
