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

From Andrew Sullivan
Subject Re: undefined behaviour for sub-transactions?
Date
Msg-id 20051130211918.GD32279@phlogiston.dyndns.org
Whole thread Raw
In response to Re: undefined behaviour for sub-transactions?  (Tim Bunce <Tim.Bunce@pobox.com>)
Responses Re: undefined behaviour for sub-transactions?
Re: undefined behaviour for sub-transactions?
Re: undefined behaviour for sub-transactions?
List pgsql-general
On Tue, Nov 29, 2005 at 07:44:05PM +0000, Tim Bunce wrote:
> On Tue, Nov 29, 2005 at 10:50:01AM -0800, Tyler MacDonald wrote:
> > PostgreSQL, doing a SELECT on a table that doesn't exist poisons the rest of
> > the transaction, whereas under MySQL and SQLite2 the transaction is allowed
> > to continue.
>
> PostgreSQL is non-standard (and inconvenient) in this respect.

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.

But it's worth knowing that in Pg 8.1 and later, you can wrap such
things in a subtransaction and get out of it that way.

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to.  That actually seems sort of quaint now.
        --J.D. Baldwin

pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Finding uniques across a big join
Next
From: Tyler MacDonald
Date:
Subject: Re: undefined behaviour for sub-transactions?