From: Tom Lane <tgl@sss.pgh.pa.us>
To: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>
cc: "Peter Eisentraut" <peter@eisentraut.org>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: allow benign typedef redefinitions (C11)
In-reply-to: <a08ed217-1bf3-4c1d-97ca-7f5ca93e53cf@app.fastmail.com>
References: <10d32190-f31b-40a5-b177-11db55597355@eisentraut.org>
 <a08ed217-1bf3-4c1d-97ca-7f5ca93e53cf@app.fastmail.com>
Comments: In-reply-to =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>
	message dated "Sun, 28 Sep 2025 11:23:51 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <832523.1759070119.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 28 Sep 2025 10:35:19 -0400
Message-ID: <832524.1759070119@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/832524.1759070119%40sss.pgh.pa.us>
Precedence: bulk

=3D?UTF-8?Q?=3DC3=3D81lvaro_Herrera?=3D <alvherre@kurilemu.de> writes:
> The changes to inet.h and varbit.h are surprising, but required.

Why?  Those headers compile now, and you've not removed any includes
that they might indirectly depend on.

> (It's possible that we should be including varatt.h in more datatype hea=
ders than just those two, but at least these are the ones that complained.=
  So another option would be to include varatt.h in the files that include=
 those headers. However, that seems to me to be the wrong direction).

If what you mean is that some of the macros in these headers require
varatt.h to be used, I do not agree that that means we should put
varatt.h into these headers.  We've frequently relied on exactly
that property of macro definitions to avoid excessive or circular
inclusions.  Moreover, even if we wanted to change that policy,
I know of no simple way to check it.

Furthermore, this whole business of using "typedef struct foo foo;"
to avoid including foo.h is predicated on the assumption that the
ultimate consumer (some .c file) will itself include foo.h, because
otherwise it's most likely gonna have problems with the incomplete
typedef.  So changing the rules about macros seems to me to be going
in quite the wrong direction.

I think what we're trying to do here is reduce the #includes of
header files to be just enough to compile the headers themselves.
That will bleed out into more #include's required in .c files,
but that's fine by me.

			regards, tom lane