From: Tatsuo Ishii <ishii@postgresql.org>
Date: Sun, 17 Feb 2019 11:23:10 +0000 (+0900)
Subject: Doc: remove ancient comment.
X-Git-Tag: aio-before-rebase-2020-06-24~3042
X-Git-Url: http://git.postgresql.org/gitweb/static/developers.postgresql.org?a=commitdiff_plain;h=69e5247879291b0164b38d17526658a72884fbe8;p=users%2Fandresfreund%2Fpostgres.git

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 3372b1ac2b..4e20664ea1 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -2434,30 +2434,6 @@ Nestloop
     in a command.
 </para>
 
-<!-- What's happening with this?  If it doesn't come back, remove this section. -->
-<!--
-<para>
-    Another situation is cases on <command>UPDATE</command> 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.
-</para>
--->
-
 <para>
     The summary is, rules will only be significantly slower than
     triggers if their actions result in large and badly qualified