Re: undefined behaviour for sub-transactions?

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Jaime Casanova <systemguards(at)gmail(dot)com>
Cc: Tyler MacDonald <tyler(at)yi(dot)org>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Jochen Wiedmann <jochen(dot)wiedmann(at)gmail(dot)com>, Paul DuBois <paul(at)snake(dot)net>, dbi-users(at)perl(dot)org, perl(at)lists(dot)mysql(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: undefined behaviour for sub-transactions?
Date: 2005-12-01 18:04:52
Message-ID: 87vey8hewr.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Jaime Casanova <systemguards(at)gmail(dot)com> writes:

> 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...

Well it's not as bad as all that. It's still "atomic" in that an interruption
cannot leave half of the transaction committed and half undone.

In other words "all" is just "all of the actions that didn't produce an
error". It's up to the client whether to commit the transaction after an error
has occurred.

It's great that Postgres follows the standard here, but don't go overboard on
the criticism of other databases either.

Where is Postgres at with psql using savepoints implicitly to wrap every
client command btw? My single biggest pet peeve with Postgres is that setting
autocommit off in psql is basically unusable because any typo forces you to
start your transaction all over again.

--
greg

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Philippe Ferreira 2005-12-01 18:07:02 Switchover : WAL archiving and shutdown...
Previous Message Kelly Burkhart 2005-12-01 17:48:28 Re: default_index_tablespace?