Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
	by hub.org (8.9.3/8.9.3) with ESMTP id PAA78032
	for <pgsql-general@postgresql.org>;
	Mon, 24 Apr 2000 15:08:32 -0400 (EDT)
	(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.93.36.246]) by Mail.austin.rr.com with
	Microsoft SMTPSVC(5.5.1877.357.35); Mon, 24 Apr 2000 13:55:11 -0500
Message-ID: <39049C1D.64AC33E6@austin.rr.com>
Date: Mon, 24 Apr 2000 14:10:21 -0500
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Manuel Lemos <mlemos@acm.org>
CC: Lincoln Yeoh <lylyeoh@mecomb.com>, tomg@admin.nrnet.org,
	pgsql-general@postgresql.org
Subject: Re: Connecting website with SQL-database.....
References: <4183.149T1516T2724477mlemos@acm.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Archive-Number: 200004/507

Manuel Lemos wrote:
> 
> >Plus if you get a warning/error, Postgresql _requires_ you to rollback,
> >whereas many other databases don't.
> 
> That's what Metabase expects. When there is an error, you should rollback
> before exiting a transaction with AutoCommit(Off).
> 
> I noticed the discussion but I could not quite figure what was the problem.

The problem on this, from my perspective, is that if you have a transaction
that consists of 20 queries, and the 14th query fails, then you'd like to
be able to abort only the *statement*, recovering in the client application
in whatever way seems appropriate.  Automatically *forcing* a rollback
takes that recovery choice away.

Regards,
Ed Loehr