On 18 August 2016 at 02:14, Gavin Flower <gavinflo...@archidevsys.co.nz> wrote:
> 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 -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
