Re: [GENERAL] undefined behaviour for sub-transactions?

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  | [email protected]
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

-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe:    http://lists.mysql.com/[email protected]