On Tue, Aug 16, 2016 at 10:47 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 8/16/16 2:52 AM, Gavin Flower wrote:
>> In both cases, part of the motivation to change from C was to appeal to
>> new developers - from what I remember of the discussions.
>
> Moving this to -hackers. Original thread at [1].
>
> tl;dr: A C++ port of Postgres has been created, and several folks on general
> have commented that this makes it easier to work with the Postgres codebase.
> This potentially attracts more developers to the project. I hope we can find
> a way to pull these folks into the fold.
>
> People in core have complained that we don't have enough hackers coming in
> (which I agree with). Part of that is lack of familiarity with C.
>
> I think we can all agree that a C++ fork of Postgres would be a huge waste
> of time, so the question becomes should core postgres start supporting C++.
>
> Peter wrote a blog about this in 2013 that makes some good arguments [2]; in
> particular "easing into" this by first officially supporting C++
> compilation. I also like the idea of investigating Rust.
I'm not really interested in supporting PostgreSQL code written in
other languages entirely, such as Rust, but I do think it would make
sense to write our code so that it can be compiled using either a C
compiler or a C++ compiler. Even if we don't ever use any C++ code in
core, this would let people who create forks or extensions use it if
they wished. It wouldn't be that much work to maintain, either: we'd
just set up some buildfarm members that compiled using C++ and when
they turned red, we'd go fix it.
I agree with your statement that one of our biggest problems is
getting more developers interested in working on PostgreSQL. Even if
there's only a 10% chance that something like this will help, why not?We're not talking about moving the earth.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
