At 10:04 AM 2/24/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.  
>> 
>> That interpretation eliminates an absolutely essential capability
>> (all-or-none behavior) in favor of what strikes me as a very minor
>> programming shortcut.
>
>The all-or-none behavior is what you get if you simply do a rollback
>on any error or warning. I don't see a special programming difficulty here.

Unfortunately (for the current implementation of Postgres) I've come
to the conclusion that this is indeed what standard SQL specifies.

It is up to the application or user to rollback the entire transaction
if that's the behavior that's desired.

Of course the whole concept of an explicit "begin" is non-standard,
too.  In SQL you're always in a transaction, commit and rollback
terminate transactions and start a new one.  Oracle, at least, provides
a "autocommit" mode (which works like Postgres when you're outside a
begin/commit block).  

I suspect that most applications don't notice the difference.   Most
will catch errors and roll back the current transaction, because that's
the logical thing to do in most cases.



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

Thu, 24 Feb 2000 06:19:20 -0800
Don Baccus <dhogaza@pacifier.com>
Re: AW: AW: [HACKERS] TRANSACTIONS 
Don Baccus <dhogaza@pacifier.com> writes:
> It is up to the application or user to rollback the entire transaction
> if that's the behavior that's desired.

> Of course the whole concept of an explicit "begin" is non-standard,
> too.  In SQL you're always in a transaction, commit and rollback
> terminate transactions and start a new one.

True, although SQL doesn't mandate exactly how that is accomplished.
We have some client interfaces that provide that behavior,
and that's a compliant way of doing it AFAICS.

We ought to consider ways of providing the same behavior in psql,
but it's not gonna happen for 7.0 --- too big a change for beta.

> I suspect that most applications don't notice the difference.   Most
> will catch errors and roll back the current transaction, because that's
> the logical thing to do in most cases.

You are assuming that the app has the intelligence to do so.  A psql
script, for example, lacks that intelligence.

I do agree that this is an area where we need to do some work, but
it's not going to be a simple or small change.  We will need nested-
transaction support in the backend, and some very careful rethinking
of the client interfaces to try to avoid breaking existing apps.

			regards, tom lane

Thu, 24 Feb 2000 11:34:18 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: AW: [HACKERS] TRANSACTIONS 
At 11:34 AM 2/24/00 -0500, Tom Lane wrote:

>We ought to consider ways of providing the same behavior in psql,
>but it's not gonna happen for 7.0 --- too big a change for beta.

Oh, yeah, no doubt about that.

>> I suspect that most applications don't notice the difference.   Most
>> will catch errors and roll back the current transaction, because that's
>> the logical thing to do in most cases.
>
>You are assuming that the app has the intelligence to do so.  A psql
>script, for example, lacks that intelligence.

I did say "most", not "all".  

>
>I do agree that this is an area where we need to do some work, but
>it's not going to be a simple or small change.  We will need nested-
>transaction support in the backend, and some very careful rethinking
>of the client interfaces to try to avoid breaking existing apps.

Well...Oracle provides "autocommit" as a convenience.  Perhaps we
could let the user select between old-style or SQL92-compliant behavior
during a transition period?



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

Thu, 24 Feb 2000 08:51:46 -0800
Don Baccus <dhogaza@pacifier.com>
Re: AW: AW: [HACKERS] TRANSACTIONS 