On Tue, Aug 16, 2016 at 12:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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.
