Re: Changing constraints to deferrable

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

In response to

Responses

Browse pgsql-general by date

  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