"brian blakey" <bmb4605@yahoo.co.uk> writes:
> Shouldn't all three PQexec... functions return the same results for
> equivalent requests.
No, because they're using different underlying protocols with different
feature sets. AFAICT you do get back "INSERT 0 0" command status in
both cases, but the non-PQexec functions are using extended query
protocol which will not return tuples for a non-SELECT query. There's
a relevant comment in PortalRunMulti:
/*
* If the destination is DestRemoteExecute, change to DestNone. The
* reason is that the client won't be expecting any tuples, and indeed has
* no way to know what they are, since there is no provision for Describe
* to send a RowDescription message when this portal execution strategy is
* in effect. This presently will only affect SELECT commands added to
* non-SELECT queries by rewrite rules: such commands will be executed,
* but the results will be discarded unless you use "simple Query"
* protocol.
*/
The old simple-Query protocol is fairly laid back about this, and can
indeed tolerate several SELECTs with different row descriptors generated
from a single command. (Although PQexec has its own limitations, and
will summarily discard all but the last one...) The newer protocol is
designed to be a lot more predictable from the client's point of view,
so it won't allow that.
regards, tom lane
