Oliver wrote: > If PREPAREd statements did DEALLOCATE on transaction rollback, the > driver would have to track the set of statements that were first > PREPAREd in the current transaction so it can fix the state on the > driver side if the transaction rolls back. This is a lot of extra > complexity for no benefit I can see. And it'd get pretty nasty if nested > transactions were involved.. > > It's all somewhat moot for the JDBC driver as it's moving to using > protocol-level Parse/Bind messages instead of PREPARE/EXECUTE statements > anyway. That said, I would be very unhappy if Parse suddenly became > transactional to match the behaviour of PREPARE.
That is precisely my situation. The more I think about it, granting prepared statements transactional lifetime would force me to stop using them, period. There really is no reasonable way of using transactions to protect against this that solves the general case. Not having parse/bind to fall back on would be a disaster... Even if I could end up using parse/bind it would be nice to have a little time to get ready for this. I would humbly request that the current behavior be deprecated for one or more released versions. Merlin ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
