AW: AW: [HACKERS] TRANSACTIONS

> > In this sense a commit is not partial. The commit should commit
> > all statements that were not in error.  
> 
> That interpretation eliminates an absolutely essential capability
> (all-or-none behavior) in favor of what strikes me as a very minor
> programming shortcut.

The all-or-none behavior is what you get if you simply do a rollback
on any error or warning. I don't see a special programming difficulty here.

> 
> > All other DB's behave in this way.
> 
> I find this hard to believe, and even harder to believe that it's
> mandated by the standard.  What you're essentially claiming is that
> everyone but us has nested transactions

They don't necessarily have nested tx, although some have.
All they provide is atomicity of single statements.

> (which'd be the only way to
> roll back a single failed statement inside a transaction) and that
> SQL92 requires nested transactions --- yet it never uses the 
> phrase nor
> makes the obvious step to allowing user-specified nested transactions.

Yes, but they say "statement" when they mention the all-or-none behavior,
not transaction.

Andreas