Message-ID: <3905B190.F575D31C@austin.rr.com>
Date: Tue, 25 Apr 2000 09:54:08 -0500
From: Ed Loehr <eloehr@austin.rr.com>
MIME-Version: 1.0
To: Manuel Lemos <mlemos@acm.org>
CC: lylyeoh@mecomb.com, tomg@admin.nrnet.org, pgsql-general@postgresql.org
Subject: Re: Connecting website with SQL-database.....
References: <1315.150T22T2112775mlemos@acm.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.
> 
> The problem is that PostgreSQL lacks of transactions check points with which
> you could do what you want.  That doesn't mean that transactions work
> differently from other DBMS.  There's just only one check point to rollback:
> the transaction begining.

I think the difference with other RDBMS that I and several others were
highlighting was the *behavior* resulting from a failed statement within a
transaction (i.e., aborted transaction vs. aborted statement), but I think
your orthogonal point is still valid.

Regards,
Ed Loehr