Re: FOREIGN KEYs ... I think ... - Mailing list pgsql-sql

From nospam@hardgeus.com
Subject Re: FOREIGN KEYs ... I think ...
Date
Msg-id 60352.66.190.208.241.1136433513.squirrel@www.hardgeus.com
Whole thread Raw
In response to FOREIGN KEYs ... I think ...  ("Marc G. Fournier" <scrappy@postgresql.org>)
Responses Re: FOREIGN KEYs ... I think ...  ("Leif B. Kristensen" <leif@solumslekt.org>)
List pgsql-sql
> 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


pgsql-sql by date:

Previous
From: Jim Johannsen
Date:
Subject: Re: FOREIGN KEYs ... I think ...
Next
From: Richard Huxton
Date:
Subject: Re: JOIN question with multiple records