C++ Compatibility
Proposal
Sometimes people would like to call C++ code in the PostgreSQL backend environment... for example, in user-defined functions, triggers, access methods. And there is sometimes a need for C++ code to call back into PostgreSQL's C functions, such as the SPI interface. Many useful software packages and libraries are written in C++.
The attached series of 4 patches is meant to provide a minimal level of support for C++ aficionados to easily compile and link with the PostgreSQL backend. No new interfaces or wrappers are provided. The goal is merely to make the backend a friendlier place for developing extensions involving C++, with minimal impact on the existing C code.
The proposed change is divided into 4 patches with the hope that each will be simple and easy to review. They can be reviewed and discussed independently, and I hope some or all may be judged benign enough to be taken up into 8.5 or earlier.
Patch outline
The patches are described in more detail below. They are:
- c++reserved -- changes a few field and parameter names which happened to be C++ reserved words
- c++bookends -- adds C linkage declarations to a few header files
- c++configure -- adds C++ support to 'configure', 'make', and 'pg_config'. A new configure option --enable-cplusplus links the C++ runtime library in to the postgres backend.
- c++exception -- converts unhandled C++ exceptions to PostgreSQL elog(FATAL) errors
Controversy
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 (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 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.
Earlier discussion of C++ issues
- STL problem in stored procedures (October 2005)
- C++ -> C : Module for converting the WHERE clause to the canonical form with PostgreSQL (January 2006)
- PG Extensions: Must be statically linked? (March 2006)
- Writing triggers in C++ (February 2007)
