Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ej9oh-0002t0-OM for pgsql-docs@arkaria.postgresql.org; Tue, 06 Feb 2018 20:26:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ej9og-0002cZ-Ek for pgsql-docs@arkaria.postgresql.org; Tue, 06 Feb 2018 20:26:10 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ej9og-0002cQ-65 for pgsql-docs@lists.postgresql.org; Tue, 06 Feb 2018 20:26:10 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ej9od-0004gL-Jb for pgsql-docs@lists.postgresql.org; Tue, 06 Feb 2018 20:26:09 +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 w16KQ5Lc029453; Tue, 6 Feb 2018 15:26:05 -0500 From: Tom Lane To: Peter Eisentraut cc: pgsql-docs@lists.postgresql.org Subject: Re: Pushing btree opclass implementor's docs to the main SGML docs In-reply-to: <71530296-e555-6bca-49d0-f3361aa883f4@2ndquadrant.com> References: <23141.1517874668@sss.pgh.pa.us> <71530296-e555-6bca-49d0-f3361aa883f4@2ndquadrant.com> Comments: In-reply-to Peter Eisentraut message dated "Tue, 06 Feb 2018 14:43:05 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29451.1517948765.1@sss.pgh.pa.us> Date: Tue, 06 Feb 2018 15:26:05 -0500 Message-ID: <29452.1517948765@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Eisentraut writes: > On 2/5/18 18:51, Tom Lane wrote: >> So I can see two ways to approach this: add two new subsections at the end >> of xindex.sgml, or create a new chapter about b-trees in Part VII >> ("Internals") to go beside the existing ones about the more recently added >> index types. The latter would make more sense if anyone was inspired to >> write something comparable in length to the existing per-index-type >> chapters. But I'm not volunteering to do that, so if it's a chapter it'd >> be a mighty thin one to start with. > xindex seems better to me. Oh, I already did it as a chapter. I'm inclined to think that somebody will want to write something more there someday, and anyway it's already longer than some existing chapters ... regards, tom lane