Re: Mostly Harmless: Welcoming our C++ friends

Tom Lane wrote:
> Kurt Harriman <harriman(at)acm(dot)org> writes:
>> [ make the backend C++-compilable ]
>
> This has been proposed before, and rejected before, and I don't believe
> the arguments have changed in the least.

Hi Tom,

Of the series of four patches, the first two (c++reserved and c++bookends)
appear much the same as Jacob Rief's patch submitted in June 2007.
http://tinyurl.com/6bjcdq
(Incidentally, I only just now found that thread. I hadn't seen it
earlier because I hadn't searched the now-defunct pgsql-patches list.)

The third patch (c++configure) addresses a problem which I have not
seen discussed before: There needs to be a portable way to compile
and link C++ code.

As it stands, the third patch depends upon the first two, because the
third one can optionally compile main.c as C++. Since main.c includes
some header files in which C++ reserved words are used as identifiers,
it cannot be compiled as C++ without fixing at least a subset of those
identifiers.

However, if it is decided that the identifiers cannot be changed, then
I could revise the c++configure and c++exception patches to remove the
dependency.

Of course it can be expected that, once or twice a year, some
starry-eyed newcomer will repeat the plea for the reserved words
to be fixed, until you succumb or add it to the FAQ.

If a C++ programmer needs ereport(ERROR)s to be recast as C++
exceptions, I propose they can handle that in their own code
without special provisions being made in PostgreSQL code.
Therefore, I claim it does not need to be addressed in this
series of patches. It is a separate issue.

However, PostgreSQL code should provide a last-resort exception handler
as a backstop against C++ programming errors. That is the purpose of
the fourth patch (c++exception). C++ programmers should catch their
own exceptions, but if they let one get away, PostgresMain should try
to make sure the shared segment isn't left in a corrupt state. In
other words, PostgresMain's defense against uncaught C++ exceptions
should be approximately equivalent to its existing defense against
SIGSEGVs, null pointer dereferencing errors, and similar faults in C.

Regards,
... kurt