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

Re: [Re] Re: PREPARE and transactions

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Re] Re: PREPARE and transactions
Date: 2004-07-03 00:16:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jeroen T. Vermeulen wrote:
> On Sat, Jul 03, 2004 at 11:17:18AM +1200, Oliver Jowett wrote:
>>>So many things are true.  But _not_ doing so also breaks compatibility,
>>>so like I said, there are counterexamples.
>>This is nonsense. Not changing the current behaviour cannot break 
>>compatibility, almost by definition.
> Almost.  But prepared statements can break compatibility with code not
> aware of their existence yet--and in some cases, this does not happen if
> they behave transactionally.  It may not be a big deal, but I'm not
> convinced that the effort of supporting rollbacks in middleware is such
> a big waste of time either.

I stand by my original statement: making no change does not break 
compatibility. Please provide an example of PREPARE/EXECUTE use that 
works under 7.3/7.4 but does not work with current 7.5.

>>Please do take a look. The V3 protocol treats the set of named 
>>statements as part of the connection state, not as anything at the SQL 
>>statement level. There are also named portals to deal with if your issue 
>>is that things shouldn't be named.
> But neither of these pose as SQL statements.  It's the SQL session that
> I'm really worried about.

Parse/Bind/Execute interact with PREPARE/EXECUTE -- they share a 
namespace. Quirky as the current behaviour is, it'd be even quirkier if 
PREPARE/EXECUTE had substantially different semantics to Parse/Bind/Execute.

Please do read the V3 protocol spec:


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2004-07-03 00:33:31
Subject: Re: Subtle bug in clog.c
Previous:From: Tom LaneDate: 2004-07-02 23:43:47
Subject: Re: Nested Transactions, Abort All

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