To: Jan Bakuwel <jan.bakuwel@greenpeace.org>
cc: pgsql-sql@postgresql.org
Subject: Re: Current transaction is aborted,
	commands ignored until end of transaction block
In-reply-to: <4EFE407D.6090404@greenpeace.org> 
References: <4EFD3D32.9060902@greenpeace.org>
	<13131805-BCBB-42DF-953B-27EE36AAF213@yahoo.com>
	<4EFD79BA.50508@greenpeace.org>
	<201112301044.33861.leif@solumslekt.org>
	<4EFE407D.6090404@greenpeace.org>
Comments: In-reply-to Jan Bakuwel <jan.bakuwel@greenpeace.org>
	message dated "Sat, 31 Dec 2011 11:51:41 +1300"
Date: Fri, 30 Dec 2011 18:19:27 -0500
Message-ID: <26063.1325287167@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jan Bakuwel <jan.bakuwel@greenpeace.org> writes:
> Why-o-why have the PostgreSQL developers decided to do it this way...?

Because starting and cleaning up a subtransaction is an expensive thing.
If we had auto-rollback at the statement level, you would be paying that
overhead for every statement in every transaction, whether you need it
or not (since obviously there's no way to forecast in advance whether a
statement will fail).  Making it depend on explicit savepoints allows
the user/application to control whether that overhead is expended or
not.

If you want to pay that price all the time, there are client-side
frameworks that will do it for you, or you can roll your own easily
enough.  So we do not see it as a big deal that the database server
itself doesn't act that way.

			regards, tom lane