Re: [GENERAL] C++ port of Postgres - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] C++ port of Postgres
Date
Msg-id 28200.1471381196@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] C++ port of Postgres  (Andres Freund <andres@anarazel.de>)
Responses Re: [GENERAL] C++ port of Postgres  (Peter Geoghegan <pg@heroku.com>)
Re: [GENERAL] C++ port of Postgres  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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++.  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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Wait events monitoring future development
Next
From: Andres Freund
Date:
Subject: Re: LWLocks in DSM memory