On 2016-08-16 12:59:24 -0400, Tom Lane wrote:
> 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 don't think it's *that* hard to make our and C++ error handling play
well together, at least when compiled with a C++ compiler.
> The whole thing would make a lot more sense given a credible design
> for error handling that keeps both languages happy.
Using C++ exceptions instead of sigsetjmp()/siglongjmp, when compiled
with a C++ compiler, seems not that hard, and could easily be hidden
behind PG_TRY/CATCH/RE_THROW/END_TRY. We'd have to hide the "bottom of
the exception stack" cases like PostgresMain() behind another macro, but
to me that doesn't sound like a bad idea anyway.
I do think it makes sense to work towards being able to compile postgres
with both C++ and C compilers. Most of the work towards that is pretty
boring...
> 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.
I think the more exciting bit is type safe lists, hash tables, ...,
without having to use huge amounts of macro magic. Using actual
inheritance for Node* stuff would also surely make some code better
checked (checked casts) and easier to write (less pointless
downcasting/upcasting from Node).
