Andres Freund <and...@anarazel.de> writes: > On 2016-08-16 13:40:06 -0700, Peter Geoghegan wrote: >> Actually, come to think of it, I guess this is wrong. The problem with >> what I say here is that longjmp() and setjmp() are incompatible with >> the stack unwinding used by C++ destructors in general (exceptions are >> another issue). I think that the practical implication of that is that >> we can never use any C++ feature that hides the complexity of resource >> management, unless and until elog() is reimplemented to not use >> longjmp() and setjmp().
> FWIW, IIRC that's not true for gcc/glibc, because they IIRC use common > codepaths. But obviously that's not all-encompassing enough to rely on that. I wonder whether it'd be possible to implement the PG_TRY/CATCH macros to use C++ exceptions when building in C++. This would probably mean that C and C++ builds would be incompatible as far as loadable extensions are concerned, because it'd amount to an ABI difference. But maybe that's OK. We could certainly have the PG_MODULE_MAGIC macro guard against the case. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers