From: Billy G. A. <bil...@mu...> - 2003-06-13 06:11:03
|
In regards to the problem in Connection.binary, which commits a transaction if it has started one, but doesn't reset the "inTransaction" flag to 0: After some thought, I now believe that the transaction should not be committed after the large object is created. This would push the responsibility of commiting the transactiont to the application programmer. The sequence would usually be: 1. (optionally) perform some queries or updates. 2. create the large object. 3. store the new large object in a table 4. (optionally) perform other queries and updates. 5. commit (or rollback) the transaction. This change will allow the creation of the large object to be rolled back if a problem occurs after it's creation. Currently, the large object is commited before it is returned to the application, which, IMHO, is not the way it should be. BTW: This code was written this way when loage objects could not be succefully rolled back in PostgreSQL. This is no longer the case. Commets anyone? ------------------------------------------------------------------------ In regards to the problem is in Connection.unlink which should raise a NotSupportedError exception when a called from within a transaction in PostgreSQL < 7.1.0, I will apply the patch. ___________________________________________________________________________ ____ | Billy G. Allie | Domain....: Bil...@mu... | /| | 7436 Hartwell | MSN.......: B_G...@em... |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 | |