On 2016-08-16 16:59:56 -0400, Tom Lane wrote:
> Andres Freund <andres@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.
