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