In another thread, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Well, the rule system is fundamentally a macro-expansion mechanism, > and multiple-evaluation risks come with that territory. There are > things you can do with macro expansion that can't be done any other > way, so I don't think that that decision was wrong on its face, but > certainly we've seen plenty of traps for the unwary in it. Can you describe, or point me to somewhere which describes, all the things you can do with a rule that you can't do with a trigger? The only examples of rules in the manual are (1) logging, which I've just been told is much better done with a trigger, and (2) making update, insert, and delete work for a view, which is the only way to do it because views are not allowed to have update, insert, or delete triggers. However, as I have learned in several recent threads, this use of rules is fraught with difficulties, especially when the view has more than one table, and it seems that it would be much easier if triggers were just allowed on views. What is the real purpose of the rule system? Mike
