trying to do this exlusively in triggers is a forray into folly.
take advantage of "instead of" or "do also" rules to create a compound
statement before your triggers do their work. (in terms of maintenance
and sanity, it's best if a trigger touches only its own record.)
as a handsweep example:
create view tree_v as select * from tree;
grant select, insert, update on tree_v to public;
create or replace rule 'tree_update' as on update to tree_v
do instead( -- update tree set seq = seq+1 where old.pnt=new.pnt and old.seq<new.seq-1 and pnt = old.pnt and seq
betweenold.seq and new.neq; -- update tree set set = new.seq where old.pnt=new.pnt and old.seq != new.seq and pnt =
old.pntand seq = new.seq;
);
note two conditions on the where clause: first is rule when to do it,
and second is what record to do it on.
you might not need the intermediate view, but I always use a view
between my app and the table - for reasons like this and many, many
others.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com