RE: AW: [HACKERS] TRANSACTIONS - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: AW: [HACKERS] TRANSACTIONS
Date
Msg-id NDBBIJLOILGIKBGDINDFMEPFCCAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: AW: [HACKERS] TRANSACTIONS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
>
> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> >> You are absolutely right.  The whole point is that either a) everything
> >> commits or b) nothing commits.
> >> Having some kinds of exceptions allow a partial commit while other
> >> exceptions rollback the transaction seems like a very error-prone
> >> programming environment to me.
>
> > In this sense a commit is not partial. The commit should commit
> > all statements that were not in error.
>
> That interpretation eliminates an absolutely essential capability
> (all-or-none behavior) in favor of what strikes me as a very minor
> programming shortcut.
>
> > All other DB's behave in this way.
>
> I find this hard to believe,

At least Oracle does so. AFAIK,transaction cancel
could be avoided except FATAL error cases using
embedded SQL. Dupicate index error is the typical
one.

Vadim has already planned to implement savepoint.
Of cource implicit per statement rollback is one of
the case.  I have thought it had already been a
consensus.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Next
From: Don Baccus
Date:
Subject: Re: [HACKERS] interesting observatation regarding views and V7.0