Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-sql by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group