|Subject:||DBD::Pg unconditionally rolling back destroyed statements on destroy (in pg_st_deallocate_statement)|
Hi, I'm not sure why you choose to rollback when a statement handle is destroyed. This breaks the idea that the transaction should stay in the failed state until explicitly rolled back or committed. If you were, say, to then explicitly roll back to a named savepoint, it would roll back to the previous savepoint of the same name. The rollback on DBH disconnect behaviour is fine, that is fair enough, but given that statement handles may be created temporarily and then thrown away, this behaviour is a bad default IMHO.