Re: how to continue a transaction after an error?

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
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 17:38:43
Message-ID: Pine.BSF.4.21.0011140933370.67853-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql


On Tue, 14 Nov 2000, Philip Warner wrote:

> >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).

I was actually talking about commit time rollback there, not statement
time. I could theoretically see commit time non-rollback in cases of a
presumed transient internal state thing (now, I can't think of any in
practice, but...)

For a commit time check, I still think preceding with a set constraints
all immediate is better if you want to actually see if you're safe to
commit.

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Steve Wampler 2000-11-14 17:44:53 Re: Using a postgres table to maintain unique id?
Previous Message Thomas Swan 2000-11-14 17:35:01 Re: Using a postgres table to maintain unique id?