Skip site navigation (1) Skip section navigation (2)

Re: Dependency / Constraint patch

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>,<pgsql-patches(at)postgresql(dot)org>
Subject: Re: Dependency / Constraint patch
Date: 2002-06-19 11:17:41
Message-ID: 031001c21782$eda70ad0$fe01a8c0@jester (view raw or flat)
Thread:
Lists: pgsql-patches
> 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

Yes, isconstraint triggers are ignored.  Triggers were easy to toss
the names around as they inherit the name of the constraint.  The
constraint was autonamed.

> > > - 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...

No choice.  Using CREATE TRIGGER drops all dependency information with
a pgdump / restore -- not to mention the actual foreign key.  If you
want to wrap it with the above suggestion feel free.  I've got a few
other things to clean up before I could go into that.


In response to

pgsql-patches by date

Next:From: Stephan SzaboDate: 2002-06-19 14:35:51
Subject: Re: Dependency / Constraint patch
Previous:From: Christopher Kings-LynneDate: 2002-06-19 08:18:30
Subject: Re: Dependency / Constraint patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group