> Tatsuo Ishii <ishii@sraoss.co.jp> writes:
>> There's a comment beginning with:
>> <!-- What's happening with this? If it doesn't come back, remove this section. -->
>> in rules.sgml around line 2437. It seems this has been there since 2003.
>> Do we need to keep this?
>
> Well, the point is that the whole para after that is commented out.
Yes, so my question was we could safely remove the whole comment or
not.
> The para in question seems to have shown up in 20a071326, and
> at the time it began
>
> +<Para>
> + Another situation are cases on UPDATE where it depends on the
> + change of an attribute if an action should be performed or
> + not. In <ProductName>Postgres</ProductName> version 6.4, the
> + attribute specification for rule events is disabled (it will have
> + it's comeback latest in 6.5, maybe earlier
> + - stay tuned). So for now 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 allways, even if the attribute of interest cannot
>
> I think it's a safe bet at this point that that feature isn't ever
> coming back, so I'd be good with ripping out the whole para.
Ok, I will remove the comment in all supported branches (after next
moinor releases are out). Patch attached.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.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