Ken Tanzer <ken.tanzer@gmail.com> writes:
> OK, and thanks for the info. I've gleaned that rules are not "deprecated"
> in the sense that they are slated for removal, but they are rather
> discouraged. Since that's the case, wouldn't it make sense to warn users
> about this?
There's no plan to remove them, but we do encourage people to think of
triggers first. That's why the triggers chapter appears first, and why
the "rules vs. triggers" section doesn't really read as evenhanded
(to me anyway).
> In the section on "Rules vs. Triggers" (41.7), it doesn't even hint at
> this, and even says:
> *"For the things that can be implemented by both, which is best depends on
> the usage of the database."*
You're ignoring the sentence immediately before that, which is
Writing such triggers is often easier than writing rules, particularly
if complex logic is required to perform the update.
as well as the one at the end of its (short) paragraph:
However, the trigger approach is conceptually far simpler than the
rule approach, and is easier for novices to get right.
The only case where we're really encouraging people to use rules is
where the overhead of a trigger is unacceptable. Even then, this
whole section is written thinking of per-row triggers. The performance
tradeoffs would likely be quite different if using a per-statement trigger
with transition tables. But that's a very new feature, and I don't think
anyone's done serious performance comparisons of that vs. rules.
regards, tom lane
