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