Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnLVY-00CpIF-5W for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Mar 2024 16:43:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rnLVV-00EkNB-GD for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Mar 2024 16:43:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnLVU-00EkN3-OR for pgsql-hackers@lists.postgresql.org; Thu, 21 Mar 2024 16:43:09 +0000 Received: from wfout2-smtp.messagingengine.com ([64.147.123.145]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnLVR-005hPv-C1 for pgsql-hackers@postgresql.org; Thu, 21 Mar 2024 16:43:07 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.west.internal (Postfix) with ESMTP id 4C9FB1C00094; Thu, 21 Mar 2024 12:43:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 21 Mar 2024 12:43:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1711039382; x= 1711125782; bh=8GUU9X6I6aJNFVPRF+WjTNCoKPYlXmUpN+tDtVowP4A=; b=D 3ASXxw93T2R72f7Nqy5RwhlFyzSCuAVT/27tkO8w6FPh81TfWZrTGbr+jTBuCFze Afdk0E3SvW3q9RUJAp4a04ypQky7Dg8zVBb6BOGJfi1U8ARH8GJkuytfMN7+aU9r BzaX3p0RHrSajKrXsB1YFoMnC0y37R7FAkC98HDQ2Tv0i3j7AmhmdeX34Gi02/Up zn98OYRsoZQsGSqb+h0FZ5g9Vd/fWL7dZjESUs/EhzBbiOP+midQ6v11ZVvhgcI4 9cURu21lWBcxVOGRmAX7+LHj6DveT5346j9HTikQXMycZuLc96rKX4aiXGRXFTyp V5YAXZCQJ7nOa/Ryq2hOA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrleejgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeejkeff gfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Mar 2024 12:43:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1711039378; bh=xitWqamHMZ2op27GVAoGQvxRvx2nh6ye59Zxhqo0aFM=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=FNFeaJ/qaCFRJlDnLpgOOhezZ7EHetpXFOa01xCW1XrdajK03zOZn2JlIMGjWcnWb Clw+sD1rI5oQYWqo+a43gEscDr8nBxGMgVQpXfGgblmU6jEBKqKOwNvo/NKFP+/GPp U0j5VyHkw4SnVBE7D57IQNSJgkhZwnX1oiyyxd81FVeTk0cNAF5ZlNcq8tZpSqTix5 hDwTRRgQxHNvmPGf+Jruywvg2bpTmT24SzbL9H+5RWfufI2j1KwW9f8nNH2GF3+v0i nMMhAS7/5kStAxBUiRP/LlDz7g/XIQIL1WtUwx3Ga3BwlZaqQeY1oPCYm1xNu9qt/B +16zxDxcNgSbg== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 850E83C9; Thu, 21 Mar 2024 17:42:58 +0100 (CET) Date: Thu, 21 Mar 2024 17:42:58 +0100 From: Alvaro Herrera To: Robert Haas Cc: Tom Lane , Andrew Dunstan , "pgsql-hackers@postgresql.org" Subject: Re: documentation structure Message-ID: <202403211642.wbgdyu2qe3pk@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2024-Mar-21, Robert Haas wrote: > On Thu, Mar 21, 2024 at 9:38 AM Tom Lane wrote: > > I'd follow the extend.sgml precedent: have a file corresponding to the > > chapter and containing any top-level text we need, then that includes > > a file per sect1. > > OK, here's a new patch set. I've revised 0003 and 0004 to use this > approach, Great, thanks. Looking at the index in the PDF after (only) 0003, we now have this structure 62. Table Access Method Interface Definition ....................................................... 2475 63. Index Access Method Interface Definition ....................................................... 2476 63.1. Basic API Structure for Indexes .......................................................... 2476 63.2. Index Access Method Functions .......................................................... 2479 63.3. Index Scanning ................................................................................ 2485 63.4. Index Locking Considerations ............................................................. 2486 63.5. Index Uniqueness Checks .................................................................. 2487 63.6. Index Cost Estimation Functions ......................................................... 2489 64. Generic WAL Records ................................................................................. 2492 65. Custom WAL Resource Managers ................................................................. 2494 66. Built-in Index Access Methods ...................................................................... 2496 which is a bit odd: why are the two WAL chapters in the middle of the chapters 62 and 63 talking about AMs? Maybe put 66 right after 63 instead. Also, is it really better to have 62/63 first and 66 later? It sounds to me like 66 is more user-oriented and the other two are developer-oriented, so I'm inclined to suggest putting them the other way around, but I'm not really sure about this. (Also, starting chapter 66 straight with 66.1 BTree without any intro text looks a bit odd; maybe one short introductory paragraph is sufficient?) > and I've added a new 0005 that does essentially the same > thing for the PL chapters. I was looking at the PL chapters earlier today too, wondering whether this would be valuable; but I worry that there are too many sub-sub-sections there, so it could end up being a bit messy. I didn't look at the resulting output though. > 0001 and 0002 are [un]changed. Should 0002 use the include-an-entity > approach as well? Shrug, I wouldn't, doesn't look worth it. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "No es bueno caminar con un hombre muerto"