Re: BUG #5093: Prepared query gives different PGresult than exec'd equivalent

"Mike Pomraning" <mjp(at)pilcrow(dot)madison(dot)wi(dot)us> writes:
> The following short program installs a RULE to SELECT two rows INSTEAD of
> INSERTing into a VIEW.

> When it PQexec's the insertion, I get a PGresult object with PQntuples == 2.
> However, when it PREPAREs/EXECUTEs the very same SQL, the PGresult has
> PQntuples == 0.

> My expectation is that the prepared statement would return the same PGresult
> as its unprepared equivalent.

> Am I using the API incorrectly, is my expectation amiss, is this a bug,
> etc.?

This is intentional, though I'm not sure if it's documented in any
user-facing place. The reason is that prepared queries are done in the
"extended Query" protocol, which is much stricter about what sorts of
results are expected for queries: if the client sends an INSERT it is
not expecting to get back a SELECT result, so the backend suppresses
sending the result of the added-on query. The traditional "simple
Query" protocol is a lot laxer and so we just spit out whatever happens
(and in fact PQexec silently discards all but the last result, so it's
not like you're getting a full view of reality in that case either).

Per the 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.
*/

regards, tom lane