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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
