X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 519B8D1B544 for ; Tue, 30 Sep 2003 00:41:01 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 11682-02 for ; Mon, 29 Sep 2003 21:40:36 -0300 (ADT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by svr1.postgresql.org (Postfix) with SMTP id 4EE84D1B502 for ; Mon, 29 Sep 2003 21:40:32 -0300 (ADT) Received: from pcp01341166pcs.wilog301.pa.comcast.net (HELO europa.janwieck.net) (janwieck@68.80.245.191 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 Sep 2003 00:40:34 -0000 Received: from Yahoo.com (pcp01341166pcs.wilog301.pa.comcast.net [68.80.245.191]) (authenticated) by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id h8U0eT301209; Mon, 29 Sep 2003 20:40:29 -0400 Message-ID: <3F78D0E5.7050805@Yahoo.com> Date: Mon, 29 Sep 2003 20:40:05 -0400 From: Jan Wieck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: Christopher Kings-Lynne , Bruce Momjian , Stephan Szabo , Peter Childs , PostgreSQL-development Subject: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) References: <200309281940.h8SJe3O01852@candle.pha.pa.us> <3F77ABA0.4070600@familyhealth.com.au> <16699.1064809727@sss.pgh.pa.us> In-Reply-To: <16699.1064809727@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200309/1635 X-Sequence-Number: 44647 Tom Lane wrote: > Christopher Kings-Lynne 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. # #================================================== JanWieck@Yahoo.com #