Re: undefined behaviour for sub-transactions? - Mailing list pgsql-general

From Jaime Casanova
Subject Re: undefined behaviour for sub-transactions?
Date
Msg-id c2d9e70e0511301344l5c186277h5080dc5d3e8ec531@mail.gmail.com
Whole thread Raw
In response to Re: undefined behaviour for sub-transactions?  (Tyler MacDonald <tyler@yi.org>)
Responses Re: undefined behaviour for sub-transactions?  (Tyler MacDonald <tyler@yi.org>)
Re: undefined behaviour for sub-transactions?  (Greg Stark <gsstark@mit.edu>)
List pgsql-general
On 11/30/05, Tyler MacDonald <tyler@yi.org> wrote:
> Andrew Sullivan <ajs@crankycanuck.ca> wrote:
> > The inconvenience I'll grant, but the non-standard claim I think
> > needs some justification.  When the database encounters an error in a
> > transaction, it is supposed to report an error.  An error in a
> > transaction causes the whole transaction to fail: that's what the
> > atomicity rule of ACID means, I think.  I actually am sort of
> > unconvinced that SQLite's transactions are real ones -- I just did
> > some playing around with it, and it seems that any error allows you
> > to commit anyway.  Certainly, MySQL's support of transactions is
> > occasionally pretty dodgy, unless you use the strict mode.
>
>        Either way the end result is that some database drivers poison a
> transaction if there's any error, others are selective about which errors
> are fatal and which are not, and still others just don't care at all.
>

that is a mis-conception... a transaction *must* be atomic (all or nothing)...
the reason some databases act that bad is because they don't support
savepoints, and because postgres does it doesn't need that
awfulness...

--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

pgsql-general by date:

Previous
From: Tyler MacDonald
Date:
Subject: Re: undefined behaviour for sub-transactions?
Next
From: Michael Fuhr
Date:
Subject: Re: undefined behaviour for sub-transactions?