From: Peter Eisentraut <peter_e@gmx.net>
To: Achilleus Mantzios <achill@matrix.gatewaynet.com>
Subject: Re: A transaction in transaction? Possible?
Date: Wed, 10 Nov 2004 17:09:48 +0100
User-Agent: KMail/1.5.1
Cc: pgsql-sql@postgresql.org
References: <Pine.LNX.4.44.0411101756450.7535-100000@matrix.gatewaynet.com>
In-Reply-To: <Pine.LNX.4.44.0411101756450.7535-100000@matrix.gatewaynet.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200411101709.48968.peter_e@gmx.net>

Achilleus Mantzios wrote:
> In other words, now with savepoints, BEGIN; COMMIT; ROLLBACK;
> can be replaced with
> SAVEPOINT foo; RELEASE foo; ROLLBACK TO foo; respectively.
>
> If only transactions weren't a requirement for SAVEPOINTs,
> what would we then need BEGIN; COMMIT; ROLLBACK; for?

Note that under the current arrangement, it doesn't make much sense to 
"commit" a subtransaction.  It will be committed anyway when the main 
transactions commits, and you cannot commit it earlier because the main 
transaction could still roll back.  So savepoint blocks are not really 
transactions, but more like semi-transactions.

In other nested transaction models, things can be different.  If you 
have so-called open nested transactions, which expose their results to 
other transactions already before the parent transaction commits, then 
a subtransaction commit is useful.  But that behavior violates the 
isolation criterion of transactions and therefore needs additional 
facilities to behave tolerably.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/