From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Don Baccus <dhogaza(at)pacifier(dot)com> |
Cc: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'hackers'" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: AW: AW: [HACKERS] TRANSACTIONS |
Date: | 2000-02-24 16:34:18 |
Message-ID: | 22076.951410058@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Don Baccus <dhogaza(at)pacifier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-02-24 16:39:58 | Re: AW: AW: [HACKERS] TRANSACTIONS |
Previous Message | Bruce Momjian | 2000-02-24 16:33:30 | Re: [HACKERS] Minor problems reloading dump in 7.0beta1 |