From: Tatsuo Ishii Date: Sun, 17 Feb 2019 11:42:58 +0000 (+0900) Subject: Doc: remove ancient comment. X-Git-Tag: REL9_5_17~62 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=71c8ea4b68949185f9d18396237587b5f91369af;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 a55d28fe24..c5ab0c1432 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