Re: Mostly Harmless: Welcoming our C++ friends

Peter Eisentraut wrote:
> FYI, we have received patches morally equivalent to yours many times
> over the years, and they have all been rejected. You might want to
> review the archives about that.

Hi Peter,

I went back as far as 2005 in the archives, and found only this thread
covering similar territory:

* SPI-header-files safe for C++-compiler
http://groups.google.com/group/pgsql.patches/browse_frm/thread/6dab9a8134cce102/3c91e40a9e615362?lnk=gst&q=rejected+c%2B%2B#3c91e40a9e615362
or http://tinyurl.com/6bjcdq
June 2007

That patch appears approximately equivalent to the first two of my
patches, c++reserved and c++bookends. The opposing arguments in
that thread seem strained, in my opinion, conveying more heat than
light. "Hey you kids, get off my lawn!" The conclusion of the
deliberative process wasn't set down in that thread; but evidently
the arguments in favor were not sufficiently persuasive: in the
end, the patch was not applied.

The foremost opposing argument seems to have been that there
should be no attempt to alleviate the existing reserved word
problem without automatic enforcement to guarantee that never
in the future can new occurrences be introduced.

But can we not separate the two problems of (1) actual identifiers
which prevent C++ compilation today, vs. (2) hypothetical code which
someone might submit in the future? The first problem is immediate;
the second would only be troublesome if the hypothetical identifier
makes it all the way through beta testing into a release.

Post #21 in the thread, by Tom Lane on July 4 2007 at 8:05 am,
suggests an automated check for non-C++-compilable header files,
and highlights the practical difficulties caused by lack of C++
support in the build system. To invoke the C++ compiler at
present, typically one would use a hard-wired compiler name
with hard-wired flags and paths. My third patch - c++configure -
begins to address the need for a portable way to build C++ code,
compatible with the way we build C code.

The notion of converting all of PostgreSQL to C++ was touched upon.
Little would be gained, at the cost of much tedium, so I advise
against it. I wouldn't want to redo the old stuff unless there's a
clear benefit. My proposal aims to make C++ a practical choice for
adding *new* things to PostgreSQL.

A topic of great interest is the relationship between C++ exceptions
and the PostgreSQL backend's error handling based on setjmp/longjmp.
My fourth patch - c++exception - adds a backstop to limit the damage
in case a C++ exception is thrown from anywhere in the backend and
not caught. The patch converts an uncaught exception to a PostgreSQL
FATAL error, so the process can clean itself up and report its failure
rather than just silently disappearing. If C++ code doesn't catch its
exceptions, that is a programming error, similar to a segment
violation or null pointer dereference, and worthy of termination.

These four patches aren't meant to create a palace of luxury for
C++ programmers. More could be done: more sophisticated error
handling could be provided; new/delete could be hooked up to
palloc/pfree; templates and class libraries could be written.
But C++ programmers can do these things for themselves, if we
give them a fighting chance: just take away the roadblocks
(primarily the reserved words) and make it easy to compile and
link.

Regards,
... kurt

PS. A few other threads had (at least somewhat) relevant discussion.
They're listed below. I didn't find any other patches. I'd appreciate
any links or pointers to any other threads which I should look at.

* STL problem in stored procedures
http://groups.google.com/group/pgsql.general/browse_frm/thread/ee352086139df2bf/400e8133b3e87d74?tvc=1&q=stl+problem+in+stored+procedures#400e8133b3e87d74
http://tinyurl.com/5hhf2v
October 2005

* C++ -> C : Module for converting the WHERE clause to the canonical form with PostgreSQL
http://groups.google.com/group/pgsql.hackers/browse_frm/thread/6cb99c3521318653/d6f2b9509cda35c5?lnk=gst&q=tom+lane+c%2B%2B#d6f2b9509cda35c5
or http://tinyurl.com/6atqmq
January 2006

* PG Extensions: Must be statically linked?
http://groups.google.com/group/pgsql.hackers/browse_frm/thread/89d3650c52430186/c63c94680b399827?lnk=gst&q=pg+extensions+must+be+statically+linked#c63c94680b399827
or http://tinyurl.com/6q5jdz
March 2006

* Writing triggers in C++
http://groups.google.com/group/pgsql.hackers/browse_frm/thread/2a95d656b8add4dd/ded7ff4ce06ae456?lnk=gst&q=writing+triggers+in+c%2B%2B#ded7ff4ce06ae456
or http://tinyurl.com/6kx8ba
February 2007