From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Rod Taylor <rbt(at)zort(dot)ca>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Dependency / Constraint patch |
Date: | 2002-06-19 14:35:51 |
Message-ID: | 20020619072737.E74146-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Wed, 19 Jun 2002, Christopher Kings-Lynne wrote:
> Hi Rod,
>
> If you break out the following two patch items:
>
> > > - psql displays foreign keys (\d output)
> > > - Foreign key triggers are autonamed based on the constraint name
>
> I'm sure that part of the patch will get committed (so long as it's good),
> as we'd agreed already to come up with such a patch (except I never got
> around to it). Have you also modified psql to NOT dump all those hundreds
> of constraint triggers and show proper FK's instead? Make it show normal
> triggers and foreign keys as separate things...
>
> > > - pg_dump uses ALTER TABLE / ADD FOREIGN KEY
>
> The item above is trouble because it makes adding foreign keys from dumps
> very slow on large tables. The advantage of the CREATE CONSRAINT TRIGGER
> approach is that it doesn't actually _check_ the constraint.
>
> My earlier suggestion was to create a 'SET CONSTRAINTS UNCHECKED;' sort of
> transaction-only function that would make ADD FOREIGN KEY _not_ check
> constraints. I can't remember what the repsonse to that was, but we need
> something...
If it only affects ALTER TABLE / ADD FOREIGN KEY, I think it's a good
idea. I don't think we should do a general unchecked however.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-06-19 21:13:10 | Re: [Fwd: [PATCHES] contrib/showguc (was Re: revised sample |
Previous Message | Rod Taylor | 2002-06-19 11:17:41 | Re: Dependency / Constraint patch |