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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
