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.