Re: [GENERAL] C++ port of Postgres

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
Cc: Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, dandl <david(at)andl(dot)org>, Adam Brusselback <adambrusselback(at)gmail(dot)com>, Joy Arulraj <jarulraj(at)cs(dot)cmu(dot)edu>, kang joni <kangjoni76(at)gmail(dot)com>, Dmitry Igrishin <dmitigr(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: [GENERAL] C++ port of Postgres
Date: 2016-08-17 23:32:23
Message-ID: CAMsr+YE0ERoArvwGQ_hR6+zaR_zOEZhdOXOyE58qcpCtTA+eqQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 18 August 2016 at 02:14, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message James Sewell 2016-08-18 02:50:46 Re: Critical failure of standby
Previous Message Patrick B 2016-08-17 23:27:12 Re: Permissions pg_dump / import

Browse pgsql-hackers by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2016-08-17 23:49:01 Re: [RFC] Change the default of update_process_title to off
Previous Message Andres Freund 2016-08-17 23:28:38 Re: CLUSTER, reform_and_rewrite_tuple(), and parallelism