Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jc7pa-0004Ti-Tb for pgsql-docs@arkaria.postgresql.org; Fri, 22 May 2020 13:35:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jc7pY-00037U-9D for pgsql-docs@arkaria.postgresql.org; Fri, 22 May 2020 13:35:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jc7pY-000373-3S for pgsql-docs@lists.postgresql.org; Fri, 22 May 2020 13:35:20 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jc7pU-0006CG-8O for pgsql-docs@lists.postgresql.org; Fri, 22 May 2020 13:35:19 +0000 Received: from hnk.local (p1864124-ipbf1405funabasi.chiba.ocn.ne.jp [123.216.143.124]) by oss.nttdata.com (Postfix) with ESMTPSA id AF3B1600E3; Fri, 22 May 2020 22:35:09 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.2 at oss.nttdata.com Subject: Re: descriptions of pg_stat_user_functions and pg_stat_slru To: Tom Lane Cc: pgsql-docs@lists.postgresql.org References: <6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com> <23668.1589940341@sss.pgh.pa.us> <19926.1589981558@sss.pgh.pa.us> <5996.1590004403@sss.pgh.pa.us> From: Fujii Masao Message-ID: Date: Fri, 22 May 2020 22:35:09 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5996.1590004403@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/05/21 4:53, Tom Lane wrote: > Fujii Masao writes: >> On 2020/05/20 22:32, Tom Lane wrote: >>> OK by me --- that, too, would be more like the existing catalogs >>> chapter. > >> Yeah, so I'd like to propose the attached patch. > > Hmmm ... I'm not exactly convinced about sticking xreflabels onto > the s as you've done here. Presumably that would make s > render like "pg_stat_slru" not "Section 27.2.3", which I think is > not consistent with our practice elsewhere. I'd be inclined to > leave the id attributes on the s, and add xreflabels there > if we want them. > > I see that catalogs.sgml doesn't really match either of those approaches, > though. Not sure if we want to change it. It looks like people have > tended to use to substitute text for xref's to the catalog > sections, so maybe it would be better to add xreflabels there too > and simplify the references. Yeah, since I think that using is simpler than , I added xlabel in . But if we don't do that for the consistency with catalog.sgml, I think that there are two approaches. (1) Replace with when referencing to the monitoring views docs. For example, add and replace with . (2) Leave as it is. In this case, for example, references to the table of pg_stat_replication instead of the section. I prefer (1) because it's better to reference to the section rather than the table. There are thirty for monitoring views in the docs and they need to be updated. > > Other than that markup quibble, this looks fine to me. Thanks for the review! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION