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 6AA49D1B4FD for ; Tue, 30 Sep 2003 00:55:57 +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 10677-10 for ; Mon, 29 Sep 2003 21:55:32 -0300 (ADT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by svr1.postgresql.org (Postfix) with SMTP id 53000D1B522 for ; Mon, 29 Sep 2003 21:55:28 -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:55:31 -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 h8U0tR301255; Mon, 29 Sep 2003 20:55:27 -0400 Message-ID: <3F78D469.6000205@Yahoo.com> Date: Mon, 29 Sep 2003 20:55: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> <3F78D0E5.7050805@Yahoo.com> <13819.1064882905@sss.pgh.pa.us> In-Reply-To: <13819.1064882905@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/1639 X-Sequence-Number: 44651 Tom Lane wrote: > Jan Wieck writes: >> 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? > > We don't want it dumping as CREATE CONSTRAINT TRIGGER, because (a) that > loses pg_depend information and (b) it's too low-level a representation; > we couldn't ever change the implementation of foreign keys as long as > dumps look like that. That's finally 2 points, okay. > > Also, I don't see why you'd want to make such a choice at pg_dump time. > Probably better to control it at restore time. Accordingly, my proposal > if we were to go that route would be a boolean GUC variable that simply > prevents ALTER TABLE ADD FOREIGN KEY from doing the validity checks. Okay too. And this would be simple and safe enough to add it at the time being. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #