From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, pgsql-General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Changing constraints to deferrable |
Date: | 2005-03-24 05:42:33 |
Message-ID: | 87wtrx4n1y.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> On Wed, Mar 23, 2005 at 12:13:33PM -0500, Greg Stark wrote:
> >
> > Consider this a plea for an ALTER TABLE ALTER CONSTRAINT command :)
>
> Shouldn't ALTER TABLE DROP CONSTRAINT followed by ALTER TABLE ADD
> CONSTRAINT work? It does for me in simple tests. It's a little
> more work than a single ALTER TABLE ALTER CONSTRAINT would be, but
> it's less hackish than updating the system catalogs directly. Or
> am I missing something?
But I want to do *all* constraints. If I tried to do that manually for
hundreds of constraints I'm certain to get at least some of them wrong.
It would also take a long time to readd all those constraints. And there's
really no reason to have to recheck a constraint to make it deferrable.
Similarly, there's no reason to have to recheck a constraint to change its
behaviour ON DELETE and ON UPDATE.
There could be some tricky bits around making a deferrable constraint not
deferrable. And disabling a constraint would be nice too, reenabling it would
require rechecking but at least it would eliminate the error-prone manual
process of reentering the definition.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Sim Zacks | 2005-03-24 07:24:11 | Re: multi line text data/query ?bug? |
Previous Message | A. Mous | 2005-03-24 03:49:22 | Re: Simple query takes a long time on win2K |