Обсуждение: Ancient comment in rules.sgml

Поиск
Список
Период
Сортировка

Ancient comment in rules.sgml

От
Tatsuo Ishii
Дата:
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?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


Re: Ancient comment in rules.sgml

От
Tom Lane
Дата:
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.

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.

            regards, tom lane


Re: Ancient comment in rules.sgml

От
Tatsuo Ishii
Дата:
> 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

Re: Ancient comment in rules.sgml

От
Michael Paquier
Дата:
On Tue, Feb 12, 2019 at 09:45:49AM +0900, Tatsuo Ishii wrote:
>> Tatsuo Ishii <ishii@sraoss.co.jp> writes:
>> 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
> minor releases are out). Patch attached.

+1.  Looks fine to me.
--
Michael

Вложения

Re: Ancient comment in rules.sgml

От
Tatsuo Ishii
Дата:
>> Ok, I will remove the comment in all supported branches (after next
>> minor releases are out). Patch attached.
> 
> +1.  Looks fine to me.

Done.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp