From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Hannu Krosing" <hannu(at)skype(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commit turns into rollback? |
Date: | 2006-03-17 15:50:45 |
Message-ID: | e51f66da0603170750x11b58ec5sda1a946b14d5ddb6@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/17/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > 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.
Error means the actual command failed. _Doing_ something, successfully,
and still reporting error seems rather wrong.
IMHO only other behaviour than current one that is not broken
is requiring ROLLBACK for failed transactions. And that is no good
for backwards-compatibility reasons.
So -1 for changing anything.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2006-03-17 16:20:43 | Seperate command-line histories for seperate databases |
Previous Message | Tom Lane | 2006-03-17 15:21:40 | Re: Commit turns into rollback? |