Re: how to continue a transaction after an error?

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, Cristi Petrescu-Prahova <cristipp(at)lasting(dot)ro>, pgsql-sql(at)postgresql(dot)org
Subject: Re: how to continue a transaction after an error?
Date: 2000-11-14 06:43:21
Message-ID: 3.0.5.32.20001114174321.00c60c60@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

At 22:23 13/11/00 -0800, Stephan Szabo wrote:
>Admittedly, having an SQLSTATE style error code would help once we had
>that so you could actually figure out what the error was.

Yep, that would be nice.

>> Totally agree; transactions will keep locks. Release them as soon as the
>> business rules and application design says that you can. Note that
>> commit-time constraints may make the commit fail; in this case PG will
>> force a rollback, but it *should* allow corrective action and another
>> attempt at a commit.
>
>This I disagree with for commit time constraints unless stuff was changed
>between the draft I have and final wording:
> "When a <commit statement> is executed,
> all constraints are effectively checked and, if any constraint
> is not satisfied, then an exception condition is raised and the
> transaction is terminated by an implicit <rollback statement>."

Just checked the SQL99 stuff, and you are quite right - commit it terminal
no matter what.

>If you're committing then you're saying
>you're done and that you want the transaction to go away.

Not only that, but trying to unravel a constraint failure at commit-time
would (except in trivial cases) be almost impossible. Best thing is to
rollback.

>If you just
>want to check deferred constraints, there's set constraints mode.

True.

>I could
>almost see certain recoverable internal state things being worth not doing
>a rollback for, but not constraints.

Not true, eg, for FK constraints. The solution may be simple and the
application needs the option to fix it. Also, eg, the triggered data
*could* be useful in reporting the error (or fixing it in code), so an
implied rollback is less than ideal. Finally, custom 'CHECK' constraints
could be designed for exactly this purpose (I have done this in DBs before).

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Graham Vickrage 2000-11-14 13:36:15 Trigger cant find function
Previous Message Stephan Szabo 2000-11-14 06:23:57 Re: how to continue a transaction after an error?