From: | Craig Ringer <craig(at)2ndQuadrant(dot)com> |
---|---|
To: | matt(at)byrney(dot)com |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Maintaining state across function calls |
Date: | 2012-11-20 01:30:23 |
Message-ID: | 50AADD2F.8080702@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 11/19/2012 10:09 PM, matt(at)byrney(dot)com wrote:
> Thanks for your reply. A follow-up question: to use the palloc/pfree
> functions with a C++ STL container, do I simply give the container an
> allocator which uses palloc and pfree instead of the default allocator,
> which uses new and delete?
If at all possible, isolate your C++ code from the PostgreSQL aggregate
implementation. Pass the C++ code pre-allocated buffers to work with if
you can, and manage the allocations in the Pg C code. Turn your C++ code
into library that presents only `extern "C"` interfaces and opaque types
if yu can.
C++ exception handling and the PostgreSQL backend's longjmp() based
error handling will interact in exciting and interesting ways. Avoid
calling `palloc`, `pfree` etc from within C++ if you can. If you really
must, ensure that your C++ code doesn't use any RAII, stack-allocated
objects with dtors, etc.
Otherwise you'll have to translate error handling mechanisms at every
boundary between C++ and Pg code, something I'm not even certain is
possible to do reliably.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2012-11-20 01:57:57 | Re: Maintaining state across function calls |
Previous Message | Craig Ringer | 2012-11-20 01:23:54 | Re: Prepared Statement Name Truncation |