Re: Constraint Question

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Kai Hessing <kai(dot)hessing(at)hobsons(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Constraint Question
Date: 2006-03-17 17:19:49
Message-ID: 20060317171949.GA15967@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Mar 17, 2006 at 10:33:18 +0100,
Kai Hessing <kai(dot)hessing(at)hobsons(dot)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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Daniel Blaisdell 2006-03-17 17:25:41 Re: PostgreSQL scalability concerns
Previous Message Guy Fraser 2006-03-17 17:16:38 Re: PostgreSQL scalability concerns