Re: [Re] Re: PREPARE and transactions - Mailing list pgsql-hackers

Jeroen T. Vermeulen wrote:
> On Sat, Jul 03, 2004 at 12:16:50PM +1200, Oliver Jowett wrote:
>  
> 
>>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.
> 
> 
> Whether the transaction from "7.3/7.4" to "7.5" (as it stands) breaks
> compatibility was never at issue here.  There would be no point: this break
> is _between_ 7.3 and 7.4.

I think you mean "between 7.2 and 7.3".

> Middleware can no longer assume that rolling
> back will get it out of the changes it was making at the SQL level, unless
> it is in exclusive control of prepared statements.

Correctly written middleware could never assume this anyway. PREPARE was 
introduced in 7.3. So was rollback of SET changes on transaction abort. 
So a pre-7.3 middleware layer can't assume that ROLLBACK rolls back all 
connection state changes, and a 7.3+ middleware layer has already had to 
deal with PREPARE not rolling back for two release cycles.

> My point of view in this is the layered one, i.e. I'd like to be able to
> "speak SQL" to the server, as I'm doing now through libpq, and ignore how
> it gets there--at least as far as the SQL itself is concerned.  Call it a
> 2.0 vantage point.  From that angle there are no problems with giving the
> protocol's bound statements and SQL's prepared statements both different
> namespaces and different behaviour.
> 
> You seem to be taking the other view, where now that we have the extended
> query protocol, it makes no sense to have one behaviour for the protocol
> and another for SQL--and since the protocol implementation is not subject
> to transactions (except that portals live in transactions?) there is no
> point in going with transactional behaviour for a mechanism shared between
> both.

Yes. I see PREPARE/EXECUTE as a SQL-statement-level, connection-local 
way of getting control over reuse of plans that doesn't otherwise affect 
the semantics of the query. With the V3 protocol you can also do it at 
the protocol level rather than the statement level, but it's still the 
same underlying operation; why should it behave differently?

I'm not too worried, to tell the truth -- the JDBC driver has already 
moved to using the protocol-level approach, and so long as that doesn't 
change I'm happy. It just seems to me that the changes you're advocating 
are going to break more clients than they help (e.g. it would have 
required nontrivial work on the JDBC driver as of a month ago to deal 
with the change), and for no convincing reason.

-O