On Wed, Feb 25, 2004 at 12:35:07AM +0000, Tim Bunce wrote: > On Tue, Feb 24, 2004 at 03:25:09PM -0500, Andrew Pimlott wrote: > > I am using DBD::Pg, and I noticed that after a statement causes an > > error, subsequent statements (until rollback) fail with "current > > transaction is aborted, queries ignored until end of transaction". I > > found some postgres documentation[1] suggesting that it is impossible to > > continue after an error. Is this true for other drivers, and is there > > an official DBI position on this? (I couldn't find any mention in the > > DBI documentation.) > > The official DBI position is that the postgres behaviour seems silly.
I officially agree! > An error in a *statement* should rollback the effect of *just that > statement* as if it never happened. You should them be able to > continue within the same transaction doing whatever you want as if > you've never even tried executing the statement that failed. Then > finally you can call commit or rollback on the whole lot. Yes, that's exactly what I want. I guess there's nothing I can do about postgres, but I'm glad to hear that this works as I'd hoped with other drivers/DBMSs. > > Does anyone have suggestions for accomplishing something similar, all > > within one transaction? I don't know of any way to check for > > referential integrity violations without actually trying to delete the > > thing. If I can't come up with a better solution, I guess I'll just > > set disabled and forget about trying to delete. > > Or set disabled, commit, then try to delete and commit. That's a good idea. It would even be pretty easy to maintain a set of deferred statements, to be run in their own transactions, after the main transaction commits. Andrew
