"Mike Pomraning" <mjp@pilcrow.madison.wi.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
