Re: Constraint Question - Mailing list pgsql-general

From Bruno Wolff III
Subject Re: Constraint Question
Date
Msg-id 20060317171949.GA15967@wolff.to
Whole thread Raw
In response to Re: Constraint Question  (Kai Hessing <kai.hessing@hobsons.de>)
List pgsql-general
On Fri, Mar 17, 2006 at 10:33:18 +0100,
  Kai Hessing <kai.hessing@hobsons.de> wrote:
>
> OK, it is really a little bit odd. I try to explain what should be done.
> I have 1:n connection between stud and phon (One student does have
> different phonenumbers, fax, eMails, etc...). A positive status means
> that the entry is active and a negative status means that the entry is
> inactive. So I have the possibility to set individual entries in phon to
> inactive while the corresponding entry in stud is still active. But if
> the entry in stud is set to inactive all corresponding entries in phon
> should also be set to inactive.
>
> I think I will put  a Trigger on stud.status which updates the status of
> all connected tables. The only thing is, that the trigger must be
> updated every time I add a new table. So I like the idea of foreign keys
> which are doing it the reverse way and are set on the table which should
> be updated, and this table stays to be some sort of an independet module
> without the need of modifiing another table to update this one. But I
> think the trigger would be the only usable possibility. So I have to get
> a little bit used to triggers and their functions.

Foreign keys won't work for this. You are going to need to have triggers
on both the stud and phon tables.

> Is it right, that the trigger event is fired each time an UPDATE on the
> table is executed, or can it be configured only to be fired if an UPDATE
> on the status-row is performed? I think for performance reasons it would
> definitly the better way.

Currently you can't trigger on specific columns. However, the trigger could
check the status column to see if it had changed and do less work if it
hasn't.

pgsql-general by date:

Previous
From: Guy Fraser
Date:
Subject: Re: PostgreSQL scalability concerns
Next
From: "Daniel Blaisdell"
Date:
Subject: Re: PostgreSQL scalability concerns