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
