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
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 |