Tom Lane <[EMAIL PROTECTED]> writes: > David Wheeler <[EMAIL PROTECTED]> writes: >> * In DBD::Pg's dbdimp.c, the dbd_db_commit() function attempts a >> commit, and if it's successful, it then starts another >> transaction. Is this the proper behavior? The other DBDs I looked >> at don't appear to BEGIN a new transaction in the dbd_db_commit() >> function. * A similar question applies to dbd_db_rollback(). It >> does a rollback, and then BEGINs a new transaction. Should it be >> starting another transaction there? > > Both of these seem pretty bogus to me. Ideally the driver should > not issue a "begin" until the application issues the first command > of the new transaction. Otherwise you get into scenarios where idle > connections are holding open transactions, and ain't nobody gonna be > happy with that.
Perhaps I misunderstand how things are happening in the low-level protocol, but if a connection to postgres is in autocommit mode by default, which I understand to be the case, then all you need to do is have the begin_work and commit and rollback commands complain if AutoCommit is 1, and everything else complain if AutoCommit is 0 and you're not in a transaction. You've already got the AutoCommit boolean, so you would only need one more, say, InTransaction, to recognize the AutoCommit 0/no begin_work situation. If I have misunderstood and the situation is not this obvious, then I at least agree with Tom here---issuing begin before the first command in a new transaction can bite you, and I have, in fact, been bitten by exactly this when using DBD::Pg with Apache::DBI. Mike.
