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