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 1jjVqQ-0003sg-Ig for pgsql-docs@arkaria.postgresql.org; Thu, 11 Jun 2020 22:38:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jjVqP-0008W0-5z for pgsql-docs@arkaria.postgresql.org; Thu, 11 Jun 2020 22:38:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jjVqP-0008Vs-0D for pgsql-docs@lists.postgresql.org; Thu, 11 Jun 2020 22:38:45 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jjVqI-0007Pu-Mj for pgsql-docs@postgresql.org; Thu, 11 Jun 2020 22:38:43 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1jjVqG-0003Y4-Jn; Thu, 11 Jun 2020 18:38:36 -0400 Date: Thu, 11 Jun 2020 18:38:36 -0400 From: Bruce Momjian To: Peter Eisentraut Cc: Alvaro Herrera , Tom Lane , PostgreSQL-documentation Subject: Re: Adding xreflable Message-ID: <20200611223836.GA2507@momjian.us> References: <20200603223814.GA7455@alvherre.pgsql> <928c6fe4-ae7d-eea2-92ef-ff48f13f060e@2ndquadrant.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <928c6fe4-ae7d-eea2-92ef-ff48f13f060e@2ndquadrant.com> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Jun 4, 2020 at 07:11:41PM +0200, Peter Eisentraut wrote: > On 2020-06-04 00:38, Alvaro Herrera wrote: > > On 2020-Jun-02, Bruce Momjian wrote: > > > > > I can adjust things, but what logic are we following? Before my patch, > > > sepgsql had an xreflabel, and vacuumlo did not. I would like to have a > > > documented policy of where we should have xreflabels, and where not, and > > > I can then adjust things to match. I don't mind using but it is > > > confusing to be able to reference xreflabels in some places and be > > > required to use link in others. > > > > I think a possible rationale would be to *not* include xreflabel for > > elements that get numbered (so references become, e.g., "see Section 32.5"), > > and include them for those that don't -- so that they can be referenced > > at all. > > Yes, basically everything that already has a generated label doesn't need an > xreflabel. > > Also, if you apply xreflabels somewhere, it needs to be done consistently > across all siblings, so you don't get a different style of text depending on > which section you happen to link to. > > And moreover, there should be some general utility for the xreflabel, not > just the linking needs of one particular source location. > > The xreflabels used for the GUC variables are good examples of all three of > those points. > > Generally, xreflabels are a bit of antipattern IMO, so there need to be > solid arguments in favor of adding more. OK, I have reverted the patches that added xreflabels and added this text to the bottom of README.links: - xreflabels added to tags prevent the chapter/section for id's from being referenced; only the xreflabel is accessible. Therefore, use xreflabels only when linking is common, and chapter/section information is unneeded. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee