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

From Greg Stark
Subject Re: undefined behaviour for sub-transactions?
Date
Msg-id 87vey8hewr.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: undefined behaviour for sub-transactions?  (Jaime Casanova <systemguards@gmail.com>)
Responses Re: undefined behaviour for sub-transactions?
Re: undefined behaviour for sub-transactions?
Re: undefined behaviour for sub-transactions?
List pgsql-general
Jaime Casanova <systemguards@gmail.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

pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: help with utf8
Next
From: Philippe Ferreira
Date:
Subject: Switchover : WAL archiving and shutdown...