| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'Don Baccus'" <dhogaza(at)pacifier(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Jose Soares'" <jose(at)sferacarta(dot)com> |
| Cc: | "'hackers'" <pgsql-hackers(at)postgreSQL(dot)org>, "'general'" <pgsql-general(at)postgreSQL(dot)org> |
| Subject: | AW: [HACKERS] TRANSACTIONS |
| Date: | 2000-02-23 09:06:46 |
| Message-ID: | 219F68D65015D011A8E000006F8590C604AF7CF1@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Wim Ceulemans | 2000-02-23 11:09:14 | Re: [GENERAL] AW: [HACKERS] TRANSACTIONS |
| Previous Message | Zeugswetter Andreas SB | 2000-02-23 08:52:59 | AW: [HACKERS] TRANSACTIONS |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Mount | 2000-02-23 09:09:21 | RE: Splitting distributions (Was: Re: [HACKERS] ECPG / Release) |
| Previous Message | Zeugswetter Andreas SB | 2000-02-23 08:52:59 | AW: [HACKERS] TRANSACTIONS |