Re: BUG #3052: Inconsistent results from PQexec... with rules

"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