"Mike Pomraning" <m...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs