From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Rod Taylor" <rbt(at)zort(dot)ca>, "Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump and ALTER TABLE / ADD FOREIGN KEY |
Date: | 2002-06-23 05:23:59 |
Message-ID: | 004b01c21a76$2f162a00$0200a8c0@SOL |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Some have expressed that this could be quite slow for large databases,
> and want a type of:
>
> SET CONSTRAINTS UNCHECKED;
>
> However, others don't believe constraints other than foreign keys
> should go unchecked.
Well, at the moment remember taht all that other SET CONSTRAINTS commands
only affect foreign keys. However, this is a TODO to allow deferrable
unique constraints.
> Or would the below be more appropriate?:
> ALTER TABLE tab ADD FOREIGN KEY .... TRUST EXISTING DATA;
Maybe instead of TRUST EXISTING DATA, it could be just be WITHOUT CHECK or
something that uses existing keywords?
Either way, it must be a superuser-only command. I'm kinda beginning to
favour the latter now actually...
Except if we could make all constraints uncheckable, then restoring a dump
would be really fast (but risky!)
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-06-23 06:06:48 | RULE regression failure on freebsd/alpha |
Previous Message | James Thornton | 2002-06-23 05:12:11 | pg_restore: [archiver] input file does not appear to be a valid archive |