From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mike Pomraning" <mjp(at)pilcrow(dot)madison(dot)wi(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5093: Prepared query gives different PGresult than exec'd equivalent |
Date: | 2009-10-02 16:20:18 |
Message-ID: | 19835.1254500418@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-10-02 21:29:26 | Re: BUG #5090: erro |
Previous Message | Tom Lane | 2009-10-02 15:40:27 | Re: BUG #5094: bad result in dblink_get_result when async command sending |