Ancient comment in rules.sgml

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Ancient comment in rules.sgml

Tatsuo Ishii-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Ancient comment in rules.sgml

Tom Lane-2
Tatsuo Ishii <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Ancient comment in rules.sgml

Tatsuo Ishii-3
> Tatsuo Ishii <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Ancient comment in rules.sgml

Michael Paquier-2
On Tue, Feb 12, 2019 at 09:45:49AM +0900, Tatsuo Ishii wrote:
>> Tatsuo Ishii <[hidden email]> 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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ancient comment in rules.sgml

Tatsuo Ishii-3
>> 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