| Subject: | rollback in DBD::Pg::db::DESTROY = cargo cult? |
I see a comment around line 340 of Pg.xsi which is obviously incorrect:
The application has not explicitly disconnected. That's bad.
To ensure integrity we *must* issue a rollback. [...] if we don't
rollback, the server may automatically commit! Bham!
Corrupt database!
Actually PostgreSQL will never do this; it waits for the client app to
issue an *explicit* commit statement, as it should. If the Pg socket
goes down the tubes halfway through a transaction, the server will
simply rollback it (it's easy to verify with psql: start a transaction,
insert some tuples, then killall -9 psql; restart psql, the tuples are
gone).
The "Issuing rollback() for database handle being DESTROY'd without
explicit disconnect()" behavior is therefore not useful (and it has it's
own issues of robustness e.g. if the database itself went down before
DESTROY). It should be removed so that one can safely forget about a DBI
handle that is no longer needed, as is already the case with all other
kinds of Perl objects, XS or not (e.g. filehandles, sockets, GTK
widgets...).