Re: #include <funcapi.h>

Heres an interesting hack I just thought of that works:

extern "C" {
#include <postgres.h>
#include <fmgr.h>
#define using _using
#define typeid _typeid
#define typename _typename
#include <funcapi.h>
#undef using
#undef typeid
#undef typename

#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif
};

Now there is no collision with the C++ keywords.

On 26/12/2010, at 5:14 PM, Craig Ringer wrote:

> On 12/26/2010 02:14 PM, Elliot Chance wrote:
>
>> In file included from /usr/include/pgsql/server/access/heapam.h:21,
>> from /usr/include/pgsql/server/nodes/execnodes.h:18,
>> from /usr/include/pgsql/server/executor/execdesc.h:18,
>> from /usr/include/pgsql/server/executor/executor.h:17,
>> from /usr/include/pgsql/server/funcapi.h:21,
>> from xapian.cpp:4:
>> /usr/include/pgsql/server/nodes/primnodes.h:1155: error: expected unqualified-id before ‘using’
>
> You've neglected to mention which version of Pg you're compiling against, so that line number means nothing. What's the offending line of code and the surrounding few lines in primnodes.h?
>
> In any case, I think it's very likely the issue is a C/C++ incompatibility in the Pg headers. It fails for me in a different place using Pg 9.1git and g++ 4.5, complaining about the use of "private" as an identifier in fmgr.h, because it's a keyword in C++.
>
> This is one of the many reasons you should keep any code that touches the postgres innards as pure C, and call into your C++ code via "extern C" functions. The Pg headers aren't really C++ safe. Neither is Pg's longjmp-based error handling, which really won't mix well with exceptions or with stack-based objects that have dtors.
>
> --
> Craig Ringer