Re: [GENERAL] C++ port of Postgres

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, dandl <david(at)andl(dot)org>, Adam Brusselback <adambrusselback(at)gmail(dot)com>, Joy Arulraj <jarulraj(at)cs(dot)cmu(dot)edu>, kang joni <kangjoni76(at)gmail(dot)com>, Dmitry Igrishin <dmitigr(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: [GENERAL] C++ port of Postgres
Date: 2016-08-16 21:15:16
Message-ID: 20160816211516.4y7je4oyhlhvq2ch@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2016-08-16 22:07:23 Re: Any reasons for 'DO' statement not returning result?
Previous Message Peter Geoghegan 2016-08-16 21:13:53 Re: [GENERAL] C++ port of Postgres

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-08-16 21:18:37 Re: Detecting skipped data from logical slots (data silently skipped)
Previous Message Peter Geoghegan 2016-08-16 21:13:53 Re: [GENERAL] C++ port of Postgres