From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Hannu Krosing <hannu(at)skype(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commit turns into rollback? |
Date: | 2006-03-17 15:21:40 |
Message-ID: | 28921.1142608900@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Freitag, 17. Mrz 2006 16:07 schrieb Tom Lane:
>> It would also move us further away from the SQL standard. The spec says
>> that COMMIT ends the transaction, full stop, not "ends it only if you're
>> not in an error state". Of course the spec hasn't got a notion of a
>> transaction error state at all, but my point is that making COMMIT leave
>> you in the broken transaction is not an improvement compliance-wise.
> The standard does address the issue of transactions that cannot be committed
> because of an error. In 16.6. <commit statement> GR 6 it basically says that
> if the transaction cannot be completed (here: because of a constraint
> violation), then an exception condition should be raised. That is, the
> transaction is over but you get an error. I think that behavior would be
> better.
So it's not the fact that it rolls back that bugs you, it's the way that
the action is reported? We could talk about changing that maybe --- it
wouldn't break existing scripts AFAICS. It might break applications
though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2006-03-17 15:50:45 | Re: Commit turns into rollback? |
Previous Message | Peter Eisentraut | 2006-03-17 15:16:27 | Re: Commit turns into rollback? |