|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...).