Thread: AW: [HACKERS] TRANSACTIONS
> >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
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
At 10:06 AM 2/23/00 +0100, Zeugswetter Andreas SB wrote: >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. In other words, then, Postgres transactions are 100% non-standard. Interesting. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Service and other goodies at http://donb.photo.net.
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
>> 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.
> In this sense a commit is not partial. The commit should commit
> all statements that were not in error.
That interpretation eliminates an absolutely essential capability
(all-or-none behavior) in favor of what strikes me as a very minor
programming shortcut.
> All other DB's behave in this way.
I find this hard to believe, and even harder to believe that it's
mandated by the standard. What you're essentially claiming is that
everyone but us has nested transactions (which'd be the only way to
roll back a single failed statement inside a transaction) and that
SQL92 requires nested transactions --- yet it never uses the phrase nor
makes the obvious step to allowing user-specified nested transactions.
regards, tom lane