Peter Eisentraut <peter_e@gmx.net> writes:
> Take out a database other than PostgreSQL and do
> BEGIN; -- or whatever they use; might be implicit
> INSERT INTO existing_table ('legal value');
> barf;
> COMMIT;
> The INSERT will most likely succeed. The reason is that "barf" does not
> modify or access the data in the database, so it does not affect the
> transactional integrity of the database.
No; this example is completely irrelevant to our discussion. The reason
that (some) other DBMSes will allow the INSERT to take effect in the
above case is that they have savepoints, and the failure of the "barf"
command only rolls back to the savepoint not to the start of the
transaction. It's a generally-acknowledged shortcoming that we don't
have savepoints ... but this has no relevance to the question of whether
SETs should be rolled back or not. If we did have savepoints then I'd
be saying that SETs should roll back to a savepoint just like everything
else.
Please note that even in those other databases, if one replaces the
COMMIT with ROLLBACK in the above scenario, the effects of the INSERT
*will* roll back. Transpose this into current Postgres, and replace
INSERT with SET, and the effects do *not* roll back. How is that a
good idea?
regards, tom lane
