Re: Problem with aborting entire transactions on error - Mailing list pgsql-general

From Andrew Sullivan
Subject Re: Problem with aborting entire transactions on error
Date
Msg-id 20121210225750.GX9573@crankycanuck.ca
Whole thread Raw
In response to Re: Problem with aborting entire transactions on error  (Zbigniew <zbigniew2011@gmail.com>)
List pgsql-general
On Mon, Dec 10, 2012 at 06:29:49PM +0000, Zbigniew wrote:
>
> No, I'm not.
>
> It's able (I mean Postgres) to detect an error, and it's able to react
> on error. "What I'm basically asking for" is an option to change its
> reaction; that's all. Just to change a bit the thing already exisiting
> - not to add new one.

Yes, you are.  By the time Postgres has detected that there is this
thing to which it needs to react, you're already in the error state.
The only way around that is a subtransaction.

Moreover, what you're _really_ asking for is that Postgres do this
only in the right circumstances, and not when there's some other error
that isn't the error you were intending be automatically fixed.  This
is a special case of the Do What I Mean protocol, and lovely as it
would be if our programs all had artificial intelligence and could
read minds, I don't think such software is going to ship any time
soon.

Postgres is general-purpose software, so it has to be programmed for
the general purpose.  This does mean that some special cases that look
easy if you don't know anything about the underlying details require
more work on the part of the person using the general-purpose
software.  That's what optimizing for general cases buys you.

Best,

A

--
Andrew Sullivan
ajs@crankycanuck.ca


pgsql-general by date:

Previous
From: Alex Burkoff
Date:
Subject: execution plan is wrong, or the query ?
Next
From: Andrew Sullivan
Date:
Subject: Re: Problem with aborting entire transactions on error