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