From: | "Michael P(dot) Soulier" <michael_soulier(at)mitel(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: how do you get there from here? |
Date: | 2009-05-15 17:49:19 |
Message-ID: | 4A0DAB1F.4040407@mitel.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alban Hertroys wrote:
> 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.
Ok. That's from the automagickally-generated SQL from Django. I suppose
they felt it was easier to set up the FK initially deferred.
> 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.
Understood. I'll see what I can do. This migration is fully automated so
it has to, via code, detect the existing constraints, remove them and
reapply them during migration, if I go that route. I can't manually
migrate a few thousand installs in the field.
I'll follow-up if I find a good solution.
Thanks,
Mike
--
Michael P. Soulier <michael_soulier(at)mitel(dot)com>, 613-592-2122 x2522
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Clark | 2009-05-15 17:55:37 | Re: easy entry forms on a pg database |
Previous Message | Scott Mead | 2009-05-15 17:20:28 | Re: easy entry forms on a pg database |