Florian G. Pflug writes:
>>> Maybe we should create some wiki page or pgfoundry project that collects
>>> all glue code, tipps and tricks that people invented to glue C++ into
>>> the postgres backend.
>>
>> If it can be made to work, sure; in techdocs.
>
> I was thinking that two pairs of macros,
> PG_BEGIN_CPP, PG_END_CPP and
> PG_CPP_BEGIN_BACKEND, PG_CPP_END_BACKEND
> should be able to take care of the exception handling issues.
>
> You'd need to wrap any code-block that calls postgres functions that
> might do an elog(ERROR) inside PG_CPP_BEGIN_BACKEND,
> PG_CPP_END_BACKEND.
>
> Vice versa, any block of c++ code that is called from the backend would
> need to start with PG_BEGIN_CPP, and end with PG_END_CPP.
I've made positive experiences with such a setup, although I've spared
the PG_BEGIN_CPP/PG_END_CPP by doing the exception conversion in a C++
language handler that instantiates functors using the portable class
loading technique described in this paper:
<http://www.s11n.net/papers/classloading_cpp.html>
I'd be glad to help out on a pgfoundry project to make C++ a better
citizen for extending postgres.
regards,
andreas