On Tue, Nov 20, 2012 at 12:30 PM, Craig Ringer wrote:
> C++ exception handling and the PostgreSQL backend's longjmp() based
> error handling will interact in exciting and interesting ways.
Define "interesting"? You mean in Wash's sense of "Oh God, oh God,
we're going to receive signal 9"?
Not a
Craig Ringer wrote:
> 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"` interf
On 20 November 2012 01:30, Craig Ringer wrote:
> 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.
I think it's probably the case that PLV8 is the most mature example of
wrapping a
On 11/19/2012 10:09 PM, m...@byrney.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
m...@byrney.com writes:
> Thanks for this. Out of curiosity, why is a static a bad way to do this?
Well, it wouldn't allow more than one instance of the function per
query, and it wouldn't reset correctly after an error, and surely you
agree that your proposal of making the user do a separate "re
> m...@byrney.com writes:
>> The question is: what's the "best practice" way of letting a
>> C/C++-language function hang onto internal state across calls?
>
> A static variable for that is a really horrid idea. Instead use
> fcinfo->flinfo->fn_extra to point to some workspace palloc'd in the
> ap
m...@byrney.com writes:
> The question is: what's the "best practice" way of letting a
> C/C++-language function hang onto internal state across calls?
A static variable for that is a really horrid idea. Instead use
fcinfo->flinfo->fn_extra to point to some workspace palloc'd in the
appropriate c
> On 11/19/2012 08:41 PM, m...@byrney.com wrote:
>> I want to process all the records in a table through a C-language (well,
>> C++) function (i.e. one function call per row of the table) in such a
>> way
>> that the function hangs onto its internal state across calls. Something
>> like
>>
>> SELE
On 11/19/2012 08:41 PM, m...@byrney.com wrote:
> I want to process all the records in a table through a C-language (well,
> C++) function (i.e. one function call per row of the table) in such a way
> that the function hangs onto its internal state across calls. Something
> like
>
> SELECT my_funct
