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 1eiqam-0003oZ-WF for pgsql-docs@arkaria.postgresql.org; Mon, 05 Feb 2018 23:54:33 +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 1eiqam-0000NM-8C for pgsql-docs@arkaria.postgresql.org; Mon, 05 Feb 2018 23:54:32 +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 1eiqXX-0005Q7-TU for pgsql-docs@lists.postgresql.org; Mon, 05 Feb 2018 23:51:12 +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 1eiqXV-0001xe-CH for pgsql-docs@lists.postgresql.org; Mon, 05 Feb 2018 23:51:10 +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 w15Np8Wq023142 for ; Mon, 5 Feb 2018 18:51:08 -0500 From: Tom Lane To: pgsql-docs@lists.postgresql.org Subject: Pushing btree opclass implementor's docs to the main SGML docs MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23140.1517874668.1@sss.pgh.pa.us> Date: Mon, 05 Feb 2018 18:51:08 -0500 Message-ID: <23141.1517874668@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I whined in <17947.1517767809@sss.pgh.pa.us> about the lack of any good place in the main documentation to explain how to write in_range() support functions for the upcoming window RANGE patch. What I would like to do, to create such a place, is to move the last section of src/backend/access/nbtree/README (the "Notes to Operator Class Implementors" part) into the main docs. There are really two subparts to that: there's some rather abstract handwaving about the mathematical properties of a btree ordering, and then there's an API spec for the comparison support function. The RANGE patch would want to add an API spec for the in_range function. (At some point somebody might feel like adding some text about the sortsupport API too; though since it's basically impossible to do sortsupport except in C, I don't feel too bad about just pointing to sortsupport.h for now.) 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. Anybody have a preference, an objection, or a better idea? regards, tom lane