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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]