Re: AW: AW: [HACKERS] TRANSACTIONS
От | Don Baccus |
---|---|
Тема | Re: AW: AW: [HACKERS] TRANSACTIONS |
Дата | |
Msg-id | 3.0.1.32.20000224061920.01715af0@mail.pacifier.com обсуждение исходный текст |
Ответ на | AW: AW: [HACKERS] TRANSACTIONS (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Ответы |
Re: AW: AW: [HACKERS] TRANSACTIONS
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: