Обсуждение: AW: AW: [HACKERS] TRANSACTIONS

> > 
> > OK. May be I miss something.
> 
> I don't think so. Not with respect to Oracle. Andreas knows that
> Oracle implicitly commits your running transaction -- and starts
> a new one whenever a DDL statement is encountered. A large
> discussion about this arose about 4 months ago...I can't speak
> for DB2.

Yes, sorry, I think we should leave out the ddl statements here.
The real essential part is the dml statement block in this example.
Since the create table was the first statement in the block,
the only difference between the other db's is wheather the table
exists after a rollback. They will all have the table with one row in 
it after a commit.

Andreas

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
Serviceand other goodies at http://donb.photo.net.
 

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

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
Serviceand other goodies at http://donb.photo.net.