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
