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

From Zeugswetter Andreas SB
Subject AW: [HACKERS] TRANSACTIONS
Date
Msg-id 219F68D65015D011A8E000006F8590C604AF7CF1@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
Responses Re: AW: [HACKERS] TRANSACTIONS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> >I see no way that allowing the transaction to commit after an overflow
> >can be called consistent with the spec.
>
> 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.

There is no distinction between exceptions.
A statement that throws an error is not performed (including all
its triggered events) period.
There are sqlstates, that are only warnings, in which case the statement
is performed.

In this sense a commit is not partial. The commit should commit
all statements that were not in error.
All other DB's behave in this way.

Andreas

pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: [HACKERS] TRANSACTIONS
Next
From: Peter Mount
Date:
Subject: RE: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)