On 2016-08-16 16:59:56 -0400, Tom Lane wrote: > 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++.
Yea, I suggested that somewhere nearby. I think that'd be fairly easy - to me the hard part is making it possible to compile postgres with C++, not changing the exception handling itself. > 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. Right. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
