From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Mihai Gheorghiu <tanethq(at)earthlink(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Referential integrity |
Date: | 2001-10-26 14:52:40 |
Message-ID: | Pine.BSF.4.21.0110260748290.65868-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 26 Oct 2001, Mihai Gheorghiu wrote:
> I have a table named T1 that has two signature fields, F1 and F2.
> Both have referential integrity defined as references users table on update
> cascade on delete set null.
> When I try to change a certain username in users table, I get an error
> message like Referential integrity violation key referenced from T1 not
> found in users.
> My guess is that this happens if a record in T1 has both F1 and F2 with the
> value I'm trying to change. Probably the two referential integrity triggers
> act completely separately, e.g. when trigger for F1 updates F1, the record
> it is trying to save still has F2 with the old value, which violates
> referential integrity.
> Am I correct? How can I get out of this situation and still get the
> referential integrity I need.
You are probably correct. The constraint sometimes still notices the
intermediate states that are not complient and reports them as errors.
I don't know of a real workaround, although I believe I posted an
early test version of a patch that helps prevent these cases a while
ago, you may be able to find it in the archives. If not, I think
I still have it around (it's not the appropriate final patch which
is why it's not in there, but it's a reasonable temporary one I think,
unfortunately mostly untested in real systems)
From | Date | Subject | |
---|---|---|---|
Next Message | Fran Fabrizio | 2001-10-26 15:19:43 | null != null ??? |
Previous Message | Stephan Szabo | 2001-10-26 14:48:16 | Re: Database-level permissions? |