X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.2])
	by svr1.postgresql.org (Postfix) with ESMTP id F3328D1B554
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Mon, 10 Nov 2003 19:24:35 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
	with ESMTP id 69141-07
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Mon, 10 Nov 2003 15:24:06 -0400 (AST)
Received: from trade-india.com (ns5.trade-india.com [66.234.10.13])
	by svr1.postgresql.org (Postfix) with SMTP id 760FED1B553
	for <pgsql-sql@postgresql.org>; Mon, 10 Nov 2003 15:24:04 -0400 (AST)
Received: (qmail 12841 invoked from network); 10 Nov 2003 19:21:15 -0000
Received: from unknown (HELO trade-india.com) (203.145.130.142)
	by ns5.trade-india.com with SMTP; 10 Nov 2003 19:21:15 -0000
Message-ID: <3FB1366E.9030805@trade-india.com>
Date: Wed, 12 Nov 2003 00:50:14 +0530
From: Rajesh Kumar Mallah <mallah@trade-india.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rod Taylor <pg@rbt.ca>
Cc: Holger Jakobs <holger@jakobs.com>, sszabo@megazone.bigpanda.com,
	pgsql-sql@postgresql.org
Subject: Re: transaction processing after error in statement
References: <200311101237.hAACbuJ12784@bg.bib.de>
	<1068490585.25089.7.camel@jester>
In-Reply-To: <1068490585.25089.7.camel@jester>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200311/97
X-Sequence-Number: 15912

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Rod Taylor wrote:<br>
<blockquote type="cite" cite="mid1068490585.25089.7.camel@jester">
  <blockquote type="cite">
    <pre wrap="">be recovered either. When committing a transaction the effects of all
operations that did not fail will be made permanent. This is how
transaction processing is described in the literature.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I would be interested in reading that (URLs please) as I didn't see
anything in the spec that was interesting on this topic.

4.8.5 from Framework (part 01)
        An SQL-transaction (transaction) is a sequence of executions of
        SQL-statements that is atomic with respect to recovery. That is
        to say: either the execution result is completely successful, or
        it has no effect on any SQL-schemas or SQL-data.</pre>
</blockquote>
Although i am not aware of the roots of this discussion but would like
to<br>
comment at this point .<br>
<br>
When we work with sequences an aborted transaction does have<br>
a permanent effect on the last value&nbsp; of sequence. Is this behaviour <br>
not a violation of above defination of transaction ?<br>
<br>
<br>
Regds<br>
Mallah.<br>
<br>
<blockquote type="cite" cite="mid1068490585.25089.7.camel@jester">
  <pre wrap="">

The "execution result is completely successful" could certainly be used
to back up PostgreSQLs choice to force a rollback. However, it doesn't
differentiate between execution of what the user requested, and
execution of recovery procedures on the successful user elements.

Irregardless, I wish a commit on a failed transaction would throw an
error -- END is good enough for Rollback or Commit.

For PostgreSQL to implement this we need Savepoints or nested
transactions internally since in many cases data is physically written
in order to perform things like Foreign Key constraint checks.


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               <a class="moz-txt-link-freetext" href="http://www.postgresql.org/docs/faqs/FAQ.html">http://www.postgresql.org/docs/faqs/FAQ.html</a>
  </pre>
</blockquote>
<br>
</body>
</html>