On 6/29/07, Jacob Rief <[EMAIL PROTECTED]> wrote:
On Thu, 2007-28-06 at 01:15 -0400, Tom Lane wrote:
> Sure, but we don't break them just on a whim. The bottom line here is
> whether we are going to make a real commitment to making C++ usable as
> a backend extension language --- and for the reasons I mentioned, that
> would entail a lot more than renaming a few identifiers. It was already
> pointed out upthread that wrapping the inclusions in extern "C" {...}
> would fix the identifier part of the problem from the user side, so I do
No, wrong. Adding extern "C" does not fix the C++-keywords as identifiers
problem. Adding extern "C" only tells the compiler to switch off
name-mangling. A C++-compiler does not allow any kind of plain-old C in
such blocks. With some drawbacks, it is even perfectly legal to use some
C++ features inside an extern "C" block.
I think you are better off wrpapping your C++ code to small
pure-C module and export only that to Postgres-interfacing
C code. Thus you keep away making C++ seeing Postgres code.
It is really a mistake to think C as subset of C++. They are
really different languages. C-as-subset-of-C++ works only
with trivial C code. If you have big, old, real-life codebase
like Postgres, it really does not pay off to force it to comply
with C++ rules. Just to avoid the work of writing intermediate
wrapper code.
--
marko
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
