From: Tatsuo Ishii Date: Sun, 17 Feb 2019 11:42:14 +0000 (+0900) Subject: Doc: remove ancient comment. X-Git-Tag: REL9_6_13~74 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=0c2dcb9332ef6d25b4adf8ca918a7083ebb5dcdc;p=postgresql 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 --- diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 6344da9585..d51e435e0b 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