From: | Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> |
---|---|
To: | Michael P(dot) Soulier <michael_soulier(at)mitel(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: how do you get there from here? |
Date: | 2009-05-15 09:12:55 |
Message-ID: | 51E9F96F-CD48-47D6-AF98-183B2E8770BF@solfertje.student.utwente.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On May 13, 2009, at 8:48 PM, Michael P. Soulier wrote:
> Can someone suggest a better way that doesn't hit this "pending
> trigger"
> issue while in a transaction?
IIRC you had an initially deferred foreign key constraint? Do you
absolutely need that to be initially deferred, or deferrable even?
Because that's what's causing your problem, not the foreign key
constraint itself.
If that FK does need to be initially deferred, as a workaround you can
temporarily disable the foreign key while doing your updates. Easiest
is to drop the constraint, do your updates and recreate the
constraint, at which point the database will verify that the related
records match the constraint. Of course this opens a risk where a
record gets inserted that doesn't match your FK constraint which will
cause recreation to error out and your transaction to rollback.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4a0d321a10092082955122!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-05-15 14:14:01 | Re: drop table but file still exists |
Previous Message | Raymond O'Donnell | 2009-05-15 08:43:01 | Re: Where is pg_dump? |