On 01/06/10 10:48, Tom Lane wrote:
Too bad two out of the four pieces of advice are wrong (how many pieces of memory managed by the backend are allocated directly with malloc?). The other two are not wrong as far as they go, but they're certainly woefully inadequate, because no interesting backend extension is going to be able to get along without calling back into the core code.
It's a lot like mixing C++ with Symbian's longjump-based error handling. It's possible, just ugly, and requires error-handling boundaries to be carefully thought out.
Rather than saying "don't mix new/delete and malloc/free" I should've said "always be sure to release memory with the matching function to that which allocated it", thus covering palloc too. Not that you generally need to worry too much about palloc'd memory.
Personally I would reduce this section to <para> Don't. </para>
Sometimes you need or want to expose capabilities of a C++ library. So long as you do so with proper encapsulation of the C++ functionality, so that the only interfaces Pg sees are C, there's really no problem.
Nor are they likely to be happy at the end of the experience, if we blithely tell them up front that it'll work.
I've had no issues using C++ libraries in Pg server-side code. It *does* work. You just need to be careful where your error-handling and memory management style boundaries lie.
-- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
