Re: How to compile, link and use a C++ extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: jacques klein <jacques(dot)klei(at)googlemail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: How to compile, link and use a C++ extension
Date: 2015-08-14 17:28:39
Message-ID: 6731.1439573319@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2015-08-14 18:38:36 +0200, jacques klein wrote:
>> However I coudn't find any doc. about how to solve the problem of linking
>> C++ code and libs into the .so of my extension,
>> and nothing to solve the runtime-loading problem of the c++ specific .so
>> files ( for ex. to make work a simple usage std::string )

> libstdc++ (or whatever your platform uses) should be automatically
> loaded, I don't think you'll need to worry about that.

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()).

If you can build a bulletproof interface layer between your C++ code and
the surrounding C-coded backend, you can make it work, but that part won't
be any fun. There's way too much temptation to just call assorted C-coded
functions from your C++, and *that won't work* with any reliability.

There are discussions of these issues in the pgsql-hackers archives.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-08-14 18:00:46 Re: why can the isolation tester handle only one waiting process?
Previous Message Andres Freund 2015-08-14 16:51:53 Re: How to compile, link and use a C++ extension