X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 19D239DC87E; Wed, 4 Jan 2006 23:43:18 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 70942-08; Wed, 4 Jan 2006 23:43:22 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from hardgeus.com (unknown [70.158.54.226]) by postgresql.org (Postfix) with ESMTP id CE89D9DC870; Wed, 4 Jan 2006 23:43:15 -0400 (AST) Received: from www.hardgeus.com (unknown [192.168.3.4]) by hardgeus.com (Postfix) with SMTP id A78C5B0C0FA; Wed, 4 Jan 2006 21:43:01 -0600 (CST) Received: from 66.190.208.241 (SquirrelMail authenticated user nospam) by www.hardgeus.com with HTTP; Wed, 4 Jan 2006 21:58:33 -0600 (CST) Message-ID: <60352.66.190.208.241.1136433513.squirrel@www.hardgeus.com> In-Reply-To: <20060104213210.A1088@ganymede.hub.org> References: <20060104213210.A1088@ganymede.hub.org> Date: Wed, 4 Jan 2006 21:58:33 -0600 (CST) Subject: Re: FOREIGN KEYs ... I think ... From: nospam@hardgeus.com To: "Marc G. Fournier" Cc: pgsql-sql@postgresql.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.428 required=5 tests=[AWL=-0.122, NO_REAL_NAME=0.55] X-Spam-Score: 0.428 X-Spam-Level: X-Archive-Number: 200601/22 X-Sequence-Number: 23811 > Now, what I want to do is add a FOREIGN KEY (again, I think) that when > incident_summary.status is changed (either closed, or reopened), the > associated records in incident_comments are changed to the same state ... As the other responders mentioned, from the schema you described, it doesn't look like you really need two separate tables. However, if you do, foreign keys aren't what you're looking for to solve your problem. That's not what foreign keys do. The only thing a foreign key provides is a guarantee that if any records in B (the referencing table) still reference a record in table A (the referenced table) then you cannot delete that referenced record. As far as the actual data in table B being modified to match table A, that's something completely unrelated to foreign key integrity. That is something I would recommend maintaining at the application level. Or, if you're a trigger guy, do it in a trigger. John