Re: undefined behaviour for sub-transactions?

On 11/30/05, Tyler MacDonald <tyler(at)yi(dot)org> wrote:
> Andrew Sullivan <ajs(at)crankycanuck(dot)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 ;)