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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
