> On Aug 16, 2016, at 10:16 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > > On 17 August 2016 at 09:49, Andres Freund <and...@anarazel.de > <mailto:and...@anarazel.de>> wrote: > > > You need to include the files surrounded by extern "C" { }. > > I'd really like to adopt the convention used by many libraries etc of doing > this automatically - detecting a c++ compiler in the preprocessor and > wrapping in "extern "C"" . > > Having the codebase c++-clean enough to compile with a c++ compiler seems to > be the easiest way to maintain that, but means more "extern "C"" droppings in > the .c files, not just the headers. Still, pretty ignoreable. > Big +1 here, Just having community code compilable with a C++ compiler out of the box would go a long way.
Beyond that, on my end I have been working with PG now for a year and a half and here is a quick list of what I sorely miss from my C++ days: * Overloading of functions (same as in SQL) keeps naming clean * Named parameters (same as SQL) keeps code readable * Adding new function parameters with defaults so I don’t need to pass in NULL, 0, … at 20 places (again supported in SQL) * Member functions greatly help organize code * simple inheritance (as emulated today in node types) At my old employer we used C++ for the DBMS in various degrees in different components. That degree was agreed upon in coding standards, so we could pick what we like about C++ and blacklist what we didn’t. E.g. C style exception handling was prohibited Default memory management (new) was prohibited. Instead new() was overloaded and hooked into the DBMS memory manager. I see no reason why this couldn’t be done in PG. I can’t comment of compiling on a Rasperry PI, but know that my former DBMS code compiled and ran on Windows, Linux, AIX, Sun, HP, and Mac. But again, just having the community code compile so proprietary (for now) enhancements could be written in C++ would be huge. Cheers Serge
