Re: [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 1:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Aug 16, 2016 at 12:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> 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 think this might have advantages purely from the standpoint of new
> > compilers possibly offering useful warnings we don't get now.
>
> Yeah, that could be nice.
>
> > But
> > if we only go this far, I'm pretty dubious that it really helps people
> > to develop extensions in C++. Almost invariably, if you ask *why* they
> > want to do that, you'll get an answer involving C++ libraries that are
> > not going to play very nice with our error handling or memory management
> > conventions. I do not see how we could C++-ify the error handling
> without
> > making a complete break with C compilers ... which is a step I don't
> > really want to take.
>
> I agree, but we don't have to agree to change everything before we
> agree to change anything. If we got an agreement to try to make
> everything compile in both languages, that'd be more agreement than
> we've ever had before, and I'd rather take that agreement and run than
> look a gift horse in the mouth.
>
> > The whole thing would make a lot more sense given a credible design
> > for error handling that keeps both languages happy.
>
> Well, getting so that we can at least compile in both systems would
> certainly increase the chances of somebody being willing to work on
> such a design. And if nobody ever does, then at least people who want
> to fork and do research projects based on PostgreSQL will have
> slightly less work to do when they want to hack it up. PostgreSQL
> seems to be a very popular starting point for research work, but a
> paper I read recently complained about the antiquity of our code base.
> I prefer to call that backward-compatibility, but at some point people
> stop thinking of you as backward-compatible and instead think of you
> as simply backward.
>
>
I agree, this was the main reason why we wanted to add support for C++.

> > A lot of the other things people have muttered about, such as heavier
> > use of inline functions instead of macros, don't particularly need C++
> > at all.
>
> True.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>