Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtETr-0000yQ-TS for pgsql-docs@arkaria.postgresql.org; Mon, 11 Feb 2019 16:30:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gtETq-0003Ot-Gr for pgsql-docs@arkaria.postgresql.org; Mon, 11 Feb 2019 16:30:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtETq-0003Np-6L for pgsql-docs@lists.postgresql.org; Mon, 11 Feb 2019 16:30:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gtETn-0006kj-IH for pgsql-docs@lists.postgresql.org; Mon, 11 Feb 2019 16:30:48 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x1BGUj9V018813; Mon, 11 Feb 2019 11:30:45 -0500 From: Tom Lane To: Tatsuo Ishii cc: pgsql-docs@lists.postgresql.org Subject: Re: Ancient comment in rules.sgml In-reply-to: <20190211.191004.219630835457494660.t-ishii@sraoss.co.jp> References: <20190211.191004.219630835457494660.t-ishii@sraoss.co.jp> Comments: In-reply-to Tatsuo Ishii message dated "Mon, 11 Feb 2019 19:10:04 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18811.1549902645.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Feb 2019 11:30:45 -0500 Message-ID: <18812.1549902645@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Tatsuo Ishii writes: > There's a comment beginning with: > > 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 + + Another situation are cases on UPDATE where it depends on the + change of an attribute if an action should be performed or + not. In Postgres 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