Kurt Harriman <harriman@acm.org> writes:
> Suppose we were to use the C++ compiler to build all of
> PostgreSQL. Consider the alternatives: either
> A) switch over entirely to C++, no longer supporting C; or
> B) let the build farm do a nightly build with a C++ compiler
> merely as a test to verify that no C++ compilation errors
> are introduced, but continue to use C 'officially' for
> builds and releases; or
> C) support C and C++ equally, allowing the choice to be made
> by each person who builds PostgreSQL from source.
> Alternative A breaks (almost?) all existing third party
> extension code: sufficient reason to rule out this alternative.
This project isn't even willing to require that people use a C99
compiler ... you won't get far suggesting that the minimum tool be
upped to C++.
> With Alternative B, most development work would probably still
> be done in C.
s/most/all/, at least for anything that has ambitions of getting into
the core distribution. You can't code in C++ if it needs to be
C-compilable. For the same reason, I don't think alternative C is
materially different from alternative B: either way the rule is
"Write C that doesn't give a C++ compiler indigestion".
> All the extra work and trouble will be justified if there is
> a truly spectacular payoff. What magnificence awaits us when
> all of PostgreSQL is C++-compilable? I don't have a good
> answer.
Given the above constraints, I think the only real role for C++ here
would be to allow access to third-party C++ libraries as Postgres
extensions --- for instance something like an XML or numerical analysis
library. Now by definition such libraries aren't trying to call into
any core Postgres code, so it doesn't seem like converting all the
headers to be C++-safe is really an especially useful goal anyhow.
There's a subset of headers, like fmgr.h and funcapi.h, that would be
needed by the interface layer for such a project, and maybe they should
be made C++-clean.
The stumbling block, though, remains the same as I mentioned in the
message you linked to: if we fix some or all of the headers, what's the
plan for making sure that they stay fixed? Without a C++ buildfarm
member I think the chances of future breakage approach certainty. So it
seems like we have a very high initial investment to obtain something
that is really of unclear value.
regards, tom lane