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). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers