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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "brian blakey" <bmb4605(at)yahoo(dot)co(dot)uk>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3052: Inconsistent results from PQexec... with rules
Date: 2007-02-23 16:06:33
Message-ID: 27359.1172246793@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"brian blakey" <bmb4605(at)yahoo(dot)co(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Zdenek Kotala 2007-02-23 16:15:57 Re: BUG #2969: Inaccuracies in Solaris FAQ
Previous Message tomas 2007-02-23 08:52:47 Re: BUG #3034: FATAL: could not open lock file "/tmp/.s.PGSQL.5432.lock": Permission denied