On Fri, 2007-01-19 at 15:12 -0500, Merlin Moncure wrote: > The missing piece of the puzzle is the ability to recover a failed > transaction without issuing a full commit/rollback.
Agreed. AFAIK all other RDBMS interpret the SQL Standard to mean that a statement can fail with an ERROR, then further statements can then be issued and yet still successfully commit. With PostgreSQL, a commit cannot be successful following an ERROR. My understanding is that subtransactions were implemented as a way of implementing the above, if so desired, but it isn't realistic to automatically wrap every statement in a subtransaction, just in case. That can mean some pretty strange re-coding to get around that problem, when it occurs. Most people don't write their programs to rely on that behaviour, thankfully, but some do. Whether we care about compatibility with other RDBMS or not, users do frequently need their software to support multiple RDBMS. I'd like to see a TODO item to allow an *option* to be set to choose between these two transactional behaviours. - abort on error - continue on error i.e. COMMIT can/might succeed - though there are still cases where it cannot, such as a serializable exception. That's a major change I agree, but the first step to its implementation is to agree that it might be desirable to allow it. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
