Message-ID: <43A6DA39.2080509@archonet.com>
Date: Mon, 19 Dec 2005 16:05:13 +0000
From: Richard Huxton <dev@archonet.com>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: Ken Winter <ken@sunward.org>
Cc: 'PostgreSQL pg-sql list' <pgsql-sql@postgresql.org>
Subject: Re: Rule causes baffling error
References: <009c01c604b3$1b007630$6603a8c0@kenxp>
In-Reply-To: <009c01c604b3$1b007630$6603a8c0@kenxp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ken Winter wrote:
> Richard ~
> 
> Thanks for your response.
> 
> Can a trigger be written on a *view*?  I can't find anything in the
> PostgreSQL docs that answers this question.

There's nothing for them to fire against even if you could attach the 
trigger. I suppose you could have a statement-level trigger in more 
recent versions, but for row-level triggers there aren't any rows in the 
view to be affected.

> I originally wrote these actions (described in my original message) as a
> trigger on my base table, but then realized I was getting in deeper and
> deeper trouble because (a) I was getting into cascading triggers that I
> didn't want and (b) I need to enable some queries to access the base table
> without triggering these actions.  That's why I set up the view, and then I
> assumed that the only way I could implement these actions was as rules.  

Hmm - the cascading should be straightforward enough to deal with. When 
you are updating check if NEW.expiration_date_and_time = now() and if so 
exit the trigger function (since there's nothing to do anyway).

The other thing you might want to consider is whether the "live" data 
should be in the same table as the "old" data. That will depend on how 
you want to use it - conceptually is it all one continuum or is the 
"old" data just for archive purposes.

Now, having got this feature working, why do you want to bypass it? Will 
it be a specific user, involve specific patterns of values or what?

--
   Richard Huxton
   Archonet Ltd