From 0c2dcb9332ef6d25b4adf8ca918a7083ebb5dcdc Mon Sep 17 00:00:00 2001
From: Tatsuo Ishii
Date: Sun, 17 Feb 2019 20:42:14 +0900
Subject: Doc: remove ancient comment.
There's a very old comment in rules.sgml added back to 2003. It
expected to a feature coming back but it never happened. So now we can
safely remove the comment. Back-patched to all supported branches.
Discussion: https://postgr.es/m/20190211.191004.219630835457494660.t-ishii%40sraoss.co.jp
---
doc/src/sgml/rules.sgml | 24 ------------------------
1 file changed, 24 deletions(-)
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 6344da95855..d51e435e0bc 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -2434,30 +2434,6 @@ Nestloop
in a command.
-
-
- Another situation is cases on UPDATE where it depends on the
- change of an attribute if an action should be performed or
- not. The only way to
- create a rule as in the shoelace_log example is to do it with
- a rule qualification. That results in an extra query that is
- performed always, even if the attribute of interest cannot
- change at all because it does not appear in the target list
- of the initial query. When this is enabled again, it will be
- one more advantage of rules over triggers. Optimization of
- a trigger must fail by definition in this case, because the
- fact that its actions will only be done when a specific attribute
- is updated is hidden in its functionality. The definition of
- a trigger only allows to specify it on row level, so whenever a
- row is touched, the trigger must be called to make its
- decision. The rule system will know it by looking up the
- target list and will suppress the additional query completely
- if the attribute isn't touched. So the rule, qualified or not,
- will only do its scans if there ever could be something to do.
-
-]]>
-
The summary is, rules will only be significantly slower than
triggers if their actions result in large and badly qualified
--
cgit v1.2.3