Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Raise C requirement to C11
- f5e0186f865c 19 (unreleased) landed
meson: Move C99 test earlier
- 4a4038068bb2 19 (unreleased) landed
Enable MSVC conforming preprocessor
- 8fd9bb1d9654 19 (unreleased) landed
Make parseNodeString() C idiom compatible with Visual Studio 2015.
- f9f31aa91f82 16.0 cited

C11 / VS 2019

Peter Eisentraut <peter@eisentraut.org> — 2025-06-02T03:44:12Z

I propose that we raise the baseline C standard for PostgreSQL to C11
for PostgreSQL 19. This will allow us to make use of some new features,
clear away a bunch of backward compatibility cruft, unify use of
compiler-specific extensions, and narrow the range of compatibility
concerns for some efforts like improved threads support. Most compilers
other than older versions of MSVC (about which see below) have supported
C11 for quite some time and most use it by default, so for most
developers and packagers this wouldn't effectively change anything
except removing some restrictions about what features they can use.

(I mentioned some of this in my presentation at pgconf.dev; I will
repeat the relevant points here. You can see my presentation at [0].)

[0]:
https://www.pgevents.ca/events/pgconfdev2025/schedule/session/271-what-is-new-in-c-and-posix/

Here are some of the features we could use. This is just for
inspiration right now, these would all be separate proposals:

- alignas specifier to allow specifying larger alignments more portably,
e.g., for direct I/O
- noreturn, already in use but would allow removing
backwards-compatibility code
- static assertions, we currently have 12(!) different implementations
for this, could maybe cut down to 2
- allow typedef redefinitions, to untangle header files (see for example
recent discussion [1])
- anonymous unions, mostly aesthetic
- generic selection, for some more type safety in certain cases
- threads library (needs separate consideration, see [2])
- atomic types, to maybe simplify some of our atomics support

[1]:
https://www.postgresql.org/message-id/f36c0a45-98cd-40b2-a7cc-f2bf02b12890@eisentraut.org
[2]:
https://www.postgresql.org/message-id/flat/CA%2BhUKGLtmexrpMtxBRLCVePqV_dtWG-ZsEbyPrYc%2BNBB2TkNsw%40mail.gmail.com

(Note: While the term "threads" appears here, this is independent of any
work on a multithreaded server. It probably wouldn't hurt, but it's not
a hard prerequisite as far as I know.)

The minimum required compiler versions for C11 support among the most
common compilers are:
- gcc 4.6/4.7/4.9 (depending on what feature)
- clang 3.1/3.2/3.3 (depending on what feature)
- Visual Studio (VS) 2019 (2022 for threads)

I have also checked the following less common compilers:
- Oracle Developer Studio 12.6, which is in the buildfarm, supports C11
ok (manually tested)
- Intel ICC 17.0.0 is ok (not in the buildfarm, tested on godbolt)
- AIX xlclang, which is currently not supported but might come back,
also supports C11

I think this covers all relevant compilers.

Visual Studio details: As shown above, C11 would require VS 2019. The
current minimum version required by PostgreSQL 18 is VS 2015. Can we
move forward from that? There isn't much data to extrapolate a VS
version support policy from. When MSVC support was initially added in
PG8.3, it required VS 2005, which was just the latest at the time. Then
it was not changed for a long time, until PG12 required VS 2013, which
was exactly for the C99 support. Then it was changed once more for
PG16, requiring VS 2015; AFAICT, this was just to be able to clean away
some conditional C code. I don't recall any complaints about any of
that. Note that PG12/VS2013 corresponds arithmetically to PG18/VS2019,
so making a move in PG19 would be less restrictive than that previous
change. I'll also note that we haven't had any test coverage for
anything older than VS 2019 for quite some time. I also remember commit
f9f31aa91f8, where we discovered that the code didn't build with VS 2015
after one year, and that was two years ago, so it seems like there isn't
too much interest in trailing edge VS versions in general. So I feel
comfortable moving this forward.

GCC details: The oldest gcc version that we currently need to support is
gcc 4.8, which comes with RHEL 7. As alluded to above, some C11
features came later with gcc 4.9, specifically generic, threads, and
atomics. I think it would still be useful to move forward without those
features. Threads and atomics are out of scope anyway because they
require VS >=2022, which I'm not prepared to require. And generic,
well, we'll just have to do without that for the moment. We can of
course have a separate discussion sometime about when to drop RHEL 7
support, but it doesn't have to be a prerequisite for this.

(Both gcc pre-4.9 and MSVC pre-2019 do support thread-local storage,
just not the C11 spelling, so this is at least on paper not a blocker
for a multithreaded server.)

Clang details: I don't think anyone cares about clang versions that old.
There is a clang 4.0 in the build farm, but I don't think even that
has any practical relevance.

I would also set the minimum supported C++ version to C++11. This is
the level required for, for example, static assertions (and also threads
and atomic types), so it makes some sense to align this with the C side.
Compilers tend to implement C++ features before C features, so this
wouldn't set any additional requirements on compiler versions in practice.

Summary:
1. require VS 2019
2. use C11

Thoughts?