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:
http://developer.postgresql.org/docs/postgres/protocol.html
-O
