Skip site navigation (1) Skip section navigation (2)

AW: [HACKERS] TRANSACTIONS

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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

Responses

pgsql-hackers by date

Next:From: Peter MountDate: 2000-02-23 09:09:21
Subject: RE: Splitting distributions (Was: Re: [HACKERS] ECPG / Release)
Previous:From: Zeugswetter Andreas SBDate: 2000-02-23 08:52:59
Subject: AW: [HACKERS] TRANSACTIONS

pgsql-general by date

Next:From: Wim CeulemansDate: 2000-02-23 11:09:14
Subject: Re: [GENERAL] AW: [HACKERS] TRANSACTIONS
Previous:From: Zeugswetter Andreas SBDate: 2000-02-23 08:52:59
Subject: AW: [HACKERS] TRANSACTIONS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group