RE: AW: [HACKERS] TRANSACTIONS
От | Hiroshi Inoue |
---|---|
Тема | RE: AW: [HACKERS] TRANSACTIONS |
Дата | |
Msg-id | NDBBIJLOILGIKBGDINDFMEPFCCAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: AW: [HACKERS] TRANSACTIONS (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane > > Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes: > >> You are absolutely right. The whole point is that either a) everything > >> commits or b) nothing commits. > >> Having some kinds of exceptions allow a partial commit while other > >> exceptions rollback the transaction seems like a very error-prone > >> programming environment to me. > > > 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. > > > All other DB's behave in this way. > > I find this hard to believe, At least Oracle does so. AFAIK,transaction cancel could be avoided except FATAL error cases using embedded SQL. Dupicate index error is the typical one. Vadim has already planned to implement savepoint. Of cource implicit per statement rollback is one of the case. I have thought it had already been a consensus. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: