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 1v3H0n-00DoUS-8I for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Sep 2025 16:46:05 +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 1v3H0k-002g1A-Uz for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Sep 2025 16:46:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v3H0k-002fu3-4L for pgsql-hackers@lists.postgresql.org; Mon, 29 Sep 2025 16:46:03 +0000 Received: from fout-b6-smtp.messagingengine.com ([202.12.124.149]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v3H0h-000kIA-1x for pgsql-hackers@postgresql.org; Mon, 29 Sep 2025 16:46:02 +0000 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id 0D5F61D0014C; Mon, 29 Sep 2025 12:45:57 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 29 Sep 2025 12:45:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurilemu.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to; s=fm3; t=1759164356; x= 1759250756; bh=3sTf+HcJMa4IY/+8pqwVM1bVH9uxvNFvIkOp/QY27Is=; b=Z dOUClYZyKQprg48x3bg/e9Bd3Y/+CRF2jyDEcA0RTrA34LfKVJm4WjLsAjz9NEB/ mYy1czkhmWtmYfB3AqvQuYppMz/894Q6yZgp28EmMnMUZNKbWuJhY6D0RG0o8RjX ybwY3zAJrHMO91Rgnhz82UPRyPV/Qx7pQONVGtc5rot3yCbR4u/GFkLEDZ+mE36m CFp7EIS2dJepmZ9GEJhQ6aUZ0NmklP7TZqX5NE51TYmY7NKnc08iMJBM3y69nlEY BAUpIlJHxoKirdyHG7+7H4kpLMky4jwtm9Lhdy65pDV3ayRU6hK6kiBTDgl5j4QT j/6/RXqmVdk+UJ6z5k+xA== 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-sender :x-me-sender:x-sasl-enc; s=fm2; t=1759164356; x=1759250756; bh=3 sTf+HcJMa4IY/+8pqwVM1bVH9uxvNFvIkOp/QY27Is=; b=bB5sskuiJ8OJb5hyG pF67UlptyQxaj2Rmn8Wg4pZeSnsKXDDCPaAEv/eXx5v90OF6wNTZYn1Ds3pnO7+a V/Xw0iulCKk9UthCvfwjGzZX/XFbLcMW9BQ8rXPxBiMg767Cg9VEAlHhkor5QP0g HFO/z3Icay37NUuTrSzlcT343h66svGMxDqvjOqauJvqrG2Nb76EOHRgOp5uMONN glx+nUDMsvRCt0HuUHTPrH/c7u9T0VGpoS/e/ZB/tHnMVkP/JujQLJ3syGss88sO PNOE+O/d0quAu6J1Rkoyz6GGmBPkXmCfJrdJK0vKQ7qprxP0/LhTfxnSxIrYJ8oC wNHiA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdejkeehvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfggtggugfgjsehmkeerredttdejnecuhfhrohhmpemllhhvrghrohcu jfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgeskhhurhhilhgvmhhurdguvgeqnecuggftrf grthhtvghrnhepgedutedujeehudevveegheejgeelveevvedvuedtjedtkeeuhfehheeg vedtjeetnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvges khhurhhilhgvmhhurdguvgdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouh htpdhrtghpthhtohepphgvthgvrhesvghishgvnhhtrhgruhhtrdhorhhgpdhrtghpthht ohepphhgshhqlhdqhhgrtghkvghrshesphhoshhtghhrvghsqhhlrdhorhhgpdhrtghpth htohepthhglhesshhsshdrphhghhdrphgrrdhush X-ME-Proxy: Feedback-ID: ie3de48e3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 29 Sep 2025 12:45:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kurilemu.de; s=schmee; t=1759164352; bh=tpluLS7drVtEU4+wMZGkBTanjbFZX9+3Z1cZ4zPcUmQ=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=xR0Z5pSrYs5vZfVJKtSP5hL8faCQbJVQ3iKk0ITTwJn+QDTR5VqS7offK8206AC15 8CLRvo1kvXHATnyPj8hRLonDDVs4KMTt261jQXG4fEbKffulfk9grxf+Ocd6JY0JJl dIZItSROLs9a7lfs5KITYSx7R2hdsSjqvMjI3xvtXfmB6FLH7EMU7QBTiymGd75WwD jRNLUM2qK+s8v8LdW7CuTqCffyA7oZKjsUF6z7nStvSBBs+x4dqBw6a2L4NCEX6ZS2 RcgxRDiksPCOfE7fzZYKjY7l0BMgD5PY9PFYQeOFaD/tBXb2zee0xipz1MfcAAwOUP +wMEEzGUuxcvw== Received: by schmee.kurilemu.internal (Postfix, from userid 1000) id 74A0F78; Mon, 29 Sep 2025 18:45:52 +0200 (CEST) Date: Mon, 29 Sep 2025 18:45:52 +0200 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Tom Lane Cc: Peter Eisentraut , pgsql-hackers Subject: Re: allow benign typedef redefinitions (C11) Message-ID: <202509291356.o5t6ny2hoa3q@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="o5h4duhcv5ktxckg" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202509281643.jcbwanjuy7yh@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --o5h4duhcv5ktxckg Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, I was thinking about your (Tom's) idea of having some sort of header inclusion policy. Our current situation is that cross-module inclusions are quite widespread and the dependencies can probably be seen as a tight web (modules probably being defined as our subdirectories inside src/include). A blanket prohibition of inclusion of headers of other modules would certainly not work, but if we imagine that within each module we have a hierarchy of sorts, then it would make sense to have a policy that other modules can include high level headers of other modules, but not lower-level headers. For instance, it's okay if files in src/include/executor include high-level brin.h, but it's not okay if it has to include brin_tuple.h which is supposed to be lower-level. With that in mind, I gave another long stare to the doxygen reports for some of these files. It now seems to me that removing tidbitmap.h from genam.h is somewhat bogus, because after all tidbitmap.h is a legitimate "library" which is okay to be included in other headers, and the real bug here is the fact that only very recently (commit bfe56cdf9a4e in Feb 2025) it acquired htup_details.h just in order to be able to define TBM_MAX_TUPLES_PER_PAGE. If we remove htup_details.h from tidbitmap.h, and we also remove the inclusion of relcache.h by adding a typedef for Relation, then genam.h is a much better behaved header than before. Hence the attached patches. I've been looking at removing some includes from a few more headers, but I'm not happy with the overall achievement, or at least I don't have a good metric to present as a win. So I'll leave that for another day and maybe present a different way to look at the problem. One thing we should certainly do is fix the inclusion of brin_tuple.h and gin_tuple.h into tuplesort.h, as I mentioned upthread. That is definitely a mess, but I think it requires a new file. Another thing we should look into is splitting the ObjectType enum out of parsenodes.h into a new file of its own. We have objectaddress.h depending on the whole of parsenodes.h just to have that enum, for instance. I think that would be useful. I have the basic patch for that and I kinda like it, but I want to analyze it a bit more before posting to avoid rushing to conclusions. Thanks -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ Thou shalt study thy libraries and strive not to reinvent them without cause, that thy code may be short and readable and thy days pleasant and productive. (7th Commandment for C Programmers) --o5h4duhcv5ktxckg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="0001-Remove-genam.h-s-dependency-on-relcache.h.patch" From 75b7c0c7a270066ab8ccd448265b6dddd7224d09 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81lvaro=20Herrera?= Date: Sun, 28 Sep 2025 11:15:51 +0200 Subject: [PATCH 1/2] Remove genam.h's dependency on relcache.h --- contrib/btree_gist/btree_bit.c | 1 + src/backend/utils/adt/network_spgist.c | 1 + src/include/access/amapi.h | 2 ++ src/include/access/genam.h | 4 +++- src/include/access/nbtree.h | 1 + 5 files changed, 8 insertions(+), 1 deletion(-) diff --git a/contrib/btree_gist/btree_bit.c b/contrib/btree_gist/btree_bit.c index 0df2ae20d8b..9199f886097 100644 --- a/contrib/btree_gist/btree_bit.c +++ b/contrib/btree_gist/btree_bit.c @@ -8,6 +8,7 @@ #include "utils/fmgrprotos.h" #include "utils/sortsupport.h" #include "utils/varbit.h" +#include "varatt.h" /* GiST support functions */ PG_FUNCTION_INFO_V1(gbt_bit_compress); diff --git a/src/backend/utils/adt/network_spgist.c b/src/backend/utils/adt/network_spgist.c index 602276a35c3..a84747d9275 100644 --- a/src/backend/utils/adt/network_spgist.c +++ b/src/backend/utils/adt/network_spgist.c @@ -37,6 +37,7 @@ #include "catalog/pg_type.h" #include "utils/fmgrprotos.h" #include "utils/inet.h" +#include "varatt.h" static int inet_spg_node_number(const inet *val, int commonbits); diff --git a/src/include/access/amapi.h b/src/include/access/amapi.h index 2b4482dc1e6..63dd41c1f21 100644 --- a/src/include/access/amapi.h +++ b/src/include/access/amapi.h @@ -15,6 +15,8 @@ #include "access/cmptype.h" #include "access/genam.h" #include "access/stratnum.h" +#include "nodes/nodes.h" +#include "nodes/pg_list.h" /* * We don't wish to include planner header files here, since most of an index diff --git a/src/include/access/genam.h b/src/include/access/genam.h index ac62f6a6abd..9200a22bd9f 100644 --- a/src/include/access/genam.h +++ b/src/include/access/genam.h @@ -20,13 +20,15 @@ #include "nodes/tidbitmap.h" #include "storage/buf.h" #include "storage/lockdefs.h" -#include "utils/relcache.h" #include "utils/snapshot.h" /* We don't want this file to depend on execnodes.h. */ typedef struct IndexInfo IndexInfo; typedef struct TupleTableSlot TupleTableSlot; +/* or relcache.h */ +typedef struct RelationData *Relation; + /* * Struct for statistics maintained by amgettuple and amgetbitmap diff --git a/src/include/access/nbtree.h b/src/include/access/nbtree.h index 9ab467cb8fd..db1345f54c8 100644 --- a/src/include/access/nbtree.h +++ b/src/include/access/nbtree.h @@ -22,6 +22,7 @@ #include "catalog/pg_index.h" #include "lib/stringinfo.h" #include "storage/bufmgr.h" +#include "storage/dsm.h" #include "storage/shm_toc.h" #include "utils/skipsupport.h" -- 2.47.3 --o5h4duhcv5ktxckg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="0002-don-t-include-htup_details.h-in-tidbitmap.h.patch" From 79dabe8fa189be1ee084e60a1c1b2bf68fbbed3e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81lvaro=20Herrera?= Date: Mon, 29 Sep 2025 15:52:06 +0200 Subject: [PATCH 2/2] don't include htup_details.h in tidbitmap.h --- src/backend/nodes/tidbitmap.c | 1 + src/include/nodes/tidbitmap.h | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/nodes/tidbitmap.c b/src/backend/nodes/tidbitmap.c index 41031aa8f2f..fac2ba5d0ca 100644 --- a/src/backend/nodes/tidbitmap.c +++ b/src/backend/nodes/tidbitmap.c @@ -40,6 +40,7 @@ #include +#include "access/htup_details.h" #include "common/hashfn.h" #include "common/int.h" #include "nodes/bitmapset.h" diff --git a/src/include/nodes/tidbitmap.h b/src/include/nodes/tidbitmap.h index 99f795ceab5..f54e61c7190 100644 --- a/src/include/nodes/tidbitmap.h +++ b/src/include/nodes/tidbitmap.h @@ -22,7 +22,6 @@ #ifndef TIDBITMAP_H #define TIDBITMAP_H -#include "access/htup_details.h" #include "storage/itemptr.h" #include "utils/dsa.h" -- 2.47.3 --o5h4duhcv5ktxckg--