From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, jacques klein <jacques(dot)klei(at)googlemail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to compile, link and use a C++ extension |
Date: | 2015-08-14 18:30:13 |
Message-ID: | 55CE33B5.6000405@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/14/2015 02:10 PM, Peter Geoghegan wrote:
> On Fri, Aug 14, 2015 at 10:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah. The painful issues you're going to face are not that. They are
>> memory management (C++ "new" does not talk to palloc or vice versa)
>> and error handling ("throw" does not interoperate with PG_TRY()).
> It's worse than that. Any use of longjmp() will cause undefined
> behavior in C++. That's because each C++ object's destructor will not
> be called (possibly other reasons, too).
>
> I suggest looking at the PL/V8 code for an example of how to make C++
> code work as a Postgres extension. IIRC they've made specific
> trade-offs that might be useful for Jacques' use case too.
>
Yeah, although be aware that PLv8 still has odd buggy behaviours that I
am not sure are not related to some C/C++ impedance mismatch.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-08-14 18:40:13 | Re: Raising our compiler requirements for 9.6 |
Previous Message | Andrew Dunstan | 2015-08-14 18:27:49 | Re: Management of simple_eval_estate for plpgsql DO blocks |