|From:||Florian Pflug <fgp(at)phlo(dot)org>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: why do we need two snapshots per query?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Nov14, 2011, at 00:13 , Robert Haas wrote:
> On Sun, Nov 13, 2011 at 12:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> In that case you must be of the opinion that extended query protocol
>> is a bad idea and we should get rid of it, and the same for prepared
>> plans of all types. What you're basically proposing is that simple
>> query mode will act differently from other ways of submitting a query,
>> and I don't think that's a good idea.
> I don't see why anything I said would indicate that we shouldn't have
> prepared plans. It is useful for users to have the option to parse
> and plan before execution - especially if they want to execute the
> same query repeatedly - and if they choose to make use of that
> functionality, then we and they will have to deal with the fact that
> things can change between plan time and execution time.
The problem, or at least what I perceived to be the problem, is that
protocol-level support for prepared plans isn't the only reason to use
the extended query protocol. The other reasons are protocol-level control
over text vs. binary format, and out-of-line parameters.
In my experience, it's hard enough as it is to convince developers to
use statement parameters instead of interpolating them into the SQL
string. Once word gets out that the simple protocol is now has less locking
overhead than the extended protocol, it's going to get even harder...
|Next Message||Florian Pflug||2011-11-13 23:57:42||Re: FDW system columns|
|Previous Message||Tom Lane||2011-11-13 23:16:48||Regression tests fail once XID counter exceeds 2 billion|