Joern wrote: > > > This is really how transactions are supposed to work -- to maintain > > database integrity, in a transaction either everything should go through > > or nothing. It would work the same way in Oracle and other databases > > with transaction control. > > Here I fully contradict. Yes, in a transaction either everything should > go through or nothing, but it should be my decision what "everything" > is. The example I wrote works inside our application with Oracle, > Informix, Sybase Enterprise Server and Sybase SQL Anywhere without any > problems since years. >
PostgreSQL doesn't support nested transactions nor can it distinguish between errors. Any error in the transaction block causes an automatic rollback. It's definitely convenient to be able to gracefully recover, but don't expect this anytime soon in Pg. (I learned this after losing ten minutes of hand typing to a typo ;). Tom Lane wrote on pgadmin-hackers: TL> No, the real problem is that we have only one mechanism for recovering TL> to a valid state after an error, and that is transaction abort. TL> TL> Distinguishing statement abort from transaction abort will require TL> a huge amount of work --- every transaction-or-longer-lifetime data TL> structure in the backend will need to be looked at, for example, to see TL> how it can be rolled back to the proper state after a statement abort. TL> It'll probably get done someday, but don't hold your breath ... The thread can be found here: http://archives2.us.postgresql.org/pgsql-general/2001-07/msg01255.php
