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