Re: FOREIGN KEYs ... I think ...

Marc
Is the "assumption" that anytime there are comments the status
changes?

If I'm reading between the lines correctly, there could be a large
number of comments before the status changes. So no need to change
status until explicitly needed.

If there is a specific "comment" that means a status change, you
could code a trigger to check for the comment and then update the
"status". I don't really like this solution but it could work. The
front end/user should explicitly change the "status".

Marc G. Fournier wrote:

> On Wed, 4 Jan 2006, Tom Lane wrote:
>
>> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
>>
>>> 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 ...
>>
>>
>> Why not just get rid of the status column in incident_comments, and
>> treat incident_summary.status as the sole copy of the state? When you
>> need to get to it from incident_comments, you do a join.
>
>
> I may end up getting to that point ...
>
>> The foreign key you really ought to have here is from
>> incident_comments.incident_id to incident_summary.id
>> (assuming that I've understood your schema correctly).
>
>
> 'k, where I'm getting lost here is how do I get status changed in
> _comments on UPDATE of incident_summary.id? There doesn't seem to be
> anything for ON UPDATE to 'run SQL query' or some such ... or I'm
> reading old docs :( This is the part that I'm having a bugger of a
> time wrapping my head around ...
>
----

> Marc G. Fournier Hub.Org Networking Services
> (http://www.hub.org)
> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ:
> 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>