Foreign keys in pg_dump

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Foreign keys in pg_dump
Date: 2002-09-06 05:19:44
Message-ID: GNELIHDDFBOCMGBFGEFOKEBMCEAA.chriskl@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

OK,

The argument about using ALTER TABLE/ADD FOREIGN KEY in dumps was that it
caused an actual check of the data in the table, right? This was going to
be much slower than using CREATE CONSTRAINT TRIGGER.

So, why can't we do this in the SQL that pg_dump creates (TODO):

CREATE TABLE ...
ALTER TABLE/ADD FOREIGN KEY ...
update catalogs and disable triggers that the ADD FOREIGN KEY just created
...
COPY .. FROM ...
\.
update catalogs and enable triggers

Doesn't this give us the best of both worlds? ie. Keeps dependencies but
does fast COPYing?

Also, I think a new super-user (or owner) only SQL command would be nice
(TODO):

ALTER TABLE foo {DISABLE|ENABLE} TRIGGER { ALL | trigger_name [ ,... ] };

This is like MSSQL syntax (IIRC):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_
aa-az_3ied.asp
Specifies that trigger_name is enabled or disabled. When a trigger is
disabled it is still defined for the table; however, when INSERT, UPDATE, or
DELETE statements are executed against the table, the actions in the trigger
are not performed until the trigger is re-enabled.

It would certainly tidy up the dumps a bit...

Chris

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Curt Sampson 2002-09-06 05:37:59 Re: Inheritance
Previous Message Christopher Kings-Lynne 2002-09-06 04:59:56 Re: contrib/tsearch