Re: allow benign typedef redefinitions (C11)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: "Peter Eisentraut" <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allow benign typedef redefinitions (C11)
Date: 2025-09-28 14:35:19
Message-ID: 832524.1759070119@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre(at)kurilemu(dot)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 headers 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-09-28 15:41:41 Re: RFC: extensible planner state
Previous Message Tom Lane 2025-09-28 14:20:29 Re: [PATCH] GROUP BY ALL