Обсуждение: 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

> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
>
> 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,

At least Oracle does so. AFAIK,transaction cancel
could be avoided except FATAL error cases using
embedded SQL. Dupicate index error is the typical
one.

Vadim has already planned to implement savepoint.
Of cource implicit per statement rollback is one of
the case.  I have thought it had already been a
consensus.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp