From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Igor <igor(at)carcass(dot)ath(dot)cx>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: server-side extension in c++ |
Date: | 2010-06-01 06:13:02 |
Message-ID: | 4C04A4EE.4050108@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 01/06/10 11:05, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> Tom Lane wrote:
>>> Personally I would reduce this section to
>>> Don't.
>
>> Well, I would have avoided this mine-trap except we have this 9.0
>> release note item:
>> Allow use of <productname>C++</> functions in backend code (Kurt
>> Harriman, Peter Eisentraut)
>
> I'd be interested to see a section like this written by someone who'd
> actually done a nontrivial C++ extension and lived to tell the tale.
I can't speak up there - my own C++/Pg backend stuff has been fairly
trivial, and has been where I can maintain a fairly clean separation of
the C++-exposed and the Pg-backend-exposed parts. I was able to keep
things separate enough that my C++ compilation units didn't include the
Pg backend headers; they just exposed a pure C public interface. The Pg
backend-using compilation units were written in C, and talked to the C++
part over its exposed pure C interfaces.
This was very much pain-free, but I certainly wouldn't want to try to
use C++ code tightly intermixed with Pg backend-using code. It'd be a
nightmare.
--
Craig Ringer
Tech-related writing: http://soapyfrogs.blogspot.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2010-06-01 06:26:17 | Re: What Linux edition we should chose? |
Previous Message | Nilesh Govindarajan | 2010-06-01 05:39:12 | Re: What Linux edition we should chose? |