Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.1/8.9.1) with ESMTP id UAA26606
	for <pgsql-interfaces@postgreSQL.org>;
	Sun, 25 Oct 1998 20:22:44 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id UAA06875;
	Sun, 25 Oct 1998 20:22:09 -0500 (EST)
To: peter.garner@toward.com
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] aborted transactions 
In-reply-to: Your message of Sun, 25 Oct 1998 12:34:14 EDT
	<199810251234.AA50923204@piglet.toward.com>
Date: Sun, 25 Oct 1998 20:22:09 -0500
Message-ID: <6873.909364929@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Peter  Garner" <peter.garner@toward.com> writes:
> However, it seems to me that if certain
> queries fail, the current transaction is aborted and all
> queries are ignored until the transaction is ended, either
> via commit or rollback.

*Any* backend-detected "fatal" error causes the transaction to
be aborted.  I've kinda wished that transactions (atomic update)
could be separated from error-abort also, but right now the two
always go together in Postgres.

> Also if there is no begin
> transaction block, I assume that each statement is a unit
> of work and that all subsequent queries will work.

Right: a statement appearing outside any begin-transaction block
is treated as a self-contained transaction.

			regards, tom lane