Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group