My main language is Java, and there are a lot of very good reasons for rewriting Postgres in Java, but I'd never push that - as there are also many good reasons for NOT rewriting Postgres in Java!
I don't know why folks are jumping on the idea of a "rewrite". The original post mentioned a C++ port, adding C++ compatibility and adopting some C++ features. Hardly a rewrite.
I'm not convinced that's a good idea either, unless it shows compelling advantages in code clarity, performance, static checking, etc. But it's hardly a "rewrite", that's just hyperbolic.
I think that to get anywhere with this you'll need to show a more concrete plan for:
* What happens with libpq
* How this affects existing extensions and what changes they'll need
* How this affects PGXS
* What benefits this change offers. Concrete benefits with examples - performance numbers, code snippets, etc
* Compatibility impact on platform and compiler support
Since there's approximately zero chance of a "one big commit" switchover, you'll also need to present a transition plan, probably something like:
* Make all headers "extern "C"" conditionally if compiled as C++
* Add "extern "C"" to all C files conditionally if compiled as C++
* add a 'configure' option to compile as C++
* Progressively resolve C++-incompatibilities in C files and headers until the whole database compiles as c++
* Resolve any runtime issues
* Add buildfarm client support for optionally building with c++
* Switch one or more buildfarm members to build with c++ or add new ones
* Identify and fix compatibility issues on other platforms
Then down the track we'd:
* Switch to C++ builds by default
* Define a C++ coding standard/policy that strictly identifies what C++ features are permissible
* Shut down the C-only buildfarm members and start permitting some C++ feature use where appropriate
