Tom Lane wrote: > To expand on that: it's pretty hard to see how update or delete triggers > on a view would work. Insert is easy, because if left to its own > devices the system would in fact try to insert a tuple into the view > relation, and that action could fire a trigger which could redirect the > insertion someplace else. But updates and deletes require a > pre-existing target tuple, and there just aren't any of those in a view > relation. (Another way to say it is that update/delete require a CTID > column, which a view hasn't got.) > > So view update/delete appear to require a transformational-rule kind > of approach instead of an actions-on-physical-tuples kind of approach. > > If you've got a better idea we're all ears ... Would it be any easier to implement Oracle-style "instead of" triggers for views, instead of before and after triggers? Notionally this seems like a "do instead select trigger_fn()" rule, with the trigger function having complete responsibility for updating the underlying table(s). The difficultly I can see is what data to pass to the trigger function, since just passing the old and new values from the view may not be enough to work out which rows to update. But then, this is no worse than what Oracle currently does, and for many data models it is very useful. I've used rules to implement updateable views, and I would certainly have found triggers much easier to work with. In particular, certain things didn't seem to be possible at all with rules, such as "before insert" and "after delete" actions, because the "where" clause doesn't match anything at those points. With an "instead of" trigger you can obviously do whatever you want, in any order. Dean. _________________________________________________________________ Great deals on almost anything at eBay.co.uk. Search, bid, find and win on eBay today! http://clk.atdmt.com/UKM/go/msnnkmgl0010000004ukm/direct/01/
