Re: AW: [HACKERS] TRANSACTIONS

Jose Soares <jose@sferacarta.com>

From: Jose Soares <jose@sferacarta.com>
To: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
Cc: "'Don Baccus'" <dhogaza@pacifier.com>, "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'hackers'" <pgsql-hackers@postgresql.org>, "'general'" <pgsql-general@postgresql.org>
Date: 2000-02-23T14:39:17Z
Lists: pgsql-hackers
Yes Andreas this is the point, for a while I felt like "Don Quijote de la
Mancha".
I don't understand well what Standard says about this subject
but I think the PostgreSQL transactions is only for perfect people, it is
absolutely
unuseful because PostgreSQL can't distinguish between a fatal error and a
warning.


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.
>
> Andreas
>
> ************

--
Jose' Soares
Bologna, Italy                     Jose@sferacarta.com