From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "'hackers'" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | AW: AW: [HACKERS] TRANSACTIONS |
Date: | 2000-02-24 09:04:10 |
Message-ID: | 219F68D65015D011A8E000006F8590C604AF7CF3@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2000-02-24 09:08:43 | AW: AW: [HACKERS] TRANSACTIONS |
Previous Message | Jose Soares | 2000-02-24 08:50:11 | Re: [GENERAL] AW: [HACKERS] TRANSACTIONS |