Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:I think we need someway of telling postgres to suppress a foreign key check.
Well, the subtext argument here is "do we fix it by providing a way to suppress the check, or do we fix it by making the check fast enough to be tolerable?"
I think the advantages of choice (b) are obvious --- it doesn't allow bogus data to be loaded accidentally, and it doesn't create a problem with loading existing 7.3 dump files that don't know how to suppress the check.
If we find there is no way to do (b) acceptably well, then and only then would I want to consider (a).
I think I can accept it to be the choice of the DBA what to do. Pg_dump has that kind of options already, one can choose between COPY and INSERT for example. Why not adding the choice of dumping FKeys as ALTER TABLE or CREATE CONSTRAINT TRIGGER?
The whole "original" idea (way back a few years ago) of doing it with the CREATE CONSTRAINT TRIGGER command was, that your "backup" ought to be consistent anyway. Finding out that your tape contains inconsistent garbage _after_ your harddisk made that suspicious noise ... is a bit late, isn't it?
That ALTER TABLE ... ADD CONSTRAINT needs to be improved, because at the moment it is normally used we cannot make any assumptions about data consistency, no question. But just because we have such a nice and allways asked for ALTER TABLE command does not mean we have to force every DBA of every well maintained and stable system to perform hourly long nonsense-tests on known-to-be-good data.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
