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