From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | "'hackers'" <pgsql-hackers(at)postgreSQL(dot)org>, "'general'" <pgsql-general(at)postgreSQL(dot)org> |
Subject: | Re: AW: [HACKERS] TRANSACTIONS |
Date: | 2000-02-23 15:54:46 |
Message-ID: | 4315.951321286@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Chmara | 2000-02-23 16:21:53 | Re: [GENERAL] Re: [General] pgsql on win95 |
Previous Message | Bruce Momjian | 2000-02-23 15:39:50 | Re: [GENERAL] ERROR: JoinClauseSelectivity |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-02-23 15:58:20 | Re: Interested in writing a PostgreSQL article? |
Previous Message | Jan Wieck | 2000-02-23 15:34:29 | Re: [HACKERS] pltcl and LDAP |