Yes Andreas this is the point, for a while I felt like "Don Quijote de la
I don't understand well what Standard says about this subject
but I think the PostgreSQL transactions is only for perfect people, it is
unuseful because PostgreSQL can't distinguish between a fatal error and a
Zeugswetter Andreas SB wrote:
> > >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.
Bologna, Italy Jose(at)sferacarta(dot)com
In response to
pgsql-hackers by date
|Next:||From: Dmitry Samersoff||Date: 2000-02-23 14:53:13|
|Subject: RE: AW: [HACKERS] TRANSACTIONS|
|Previous:||From: sszabo||Date: 2000-02-23 14:32:10|
|Subject: Re: [HACKERS] TRANSACTIONS |
pgsql-general by date
|Next:||From: Louis Bertrand||Date: 2000-02-23 14:50:15|
|Subject: Re: [GENERAL] Tutorial|
|Previous:||From: Jose Soares||Date: 2000-02-23 13:46:54|
|Subject: Re: [HACKERS] TRANSACTIONS|