Обсуждение: 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

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
>> 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.

If it looks like a duck, walks like a duck, and quacks like a duck,
it's a duck no matter what it's called.  How would you provide atomicity
of a single statement without a transaction-equivalent implementation?
That statement might be affecting many tuples in several different
tables.  It's not noticeably easier to roll back one statement than
a whole sequence of them.
        regards, tom lane