At 10:04 AM 2/24/00 +0100, Zeugswetter Andreas SB wrote:
>
>> > 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.
Unfortunately (for the current implementation of Postgres) I've come
to the conclusion that this is indeed what standard SQL specifies.
It is up to the application or user to rollback the entire transaction
if that's the behavior that's desired.
Of course the whole concept of an explicit "begin" is non-standard,
too. In SQL you're always in a transaction, commit and rollback
terminate transactions and start a new one. Oracle, at least, provides
a "autocommit" mode (which works like Postgres when you're outside a
begin/commit block).
I suspect that most applications don't notice the difference. Most
will catch errors and roll back the current transaction, because that's
the logical thing to do in most cases.
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
