Re: Workaround for custom aggregate which would need "internal" - Mailing list pgsql-general

From Florian G. Pflug
Subject Re: Workaround for custom aggregate which would need "internal"
Date
Msg-id 443AEF07.5090603@phlo.org
Whole thread Raw
In response to Re: Workaround for custom aggregate which would need "internal" as statetype  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Workaround for custom aggregate which would need "internal" as statetype
List pgsql-general
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>
>>Using perl, and a perl-hash was even slower, so I wrote my to c-functions
>>(actualy c++), which use a STL hash_set to filter out duplicates.
>
> This makes me fairly nervous, because what's going to ensure that the
> memory used by the hash_set is reclaimed?  Particularly if the query
> errors out partway through?

hash_set can be told to use a user-defined allocator class, which in turn
can use palloc/pfree, with an appropriate memory context. I'm not
really sure what the "appropriate context" is, as using CurrentMemoryContext
leads to strange crashes. For now, i'm using the standard c++ allocator,
because I figured it should make debugging easier.

Still, the question remains how I can sanely use a c++ object as "state" of
a aggregate...

greetings, Florian Pflug



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Workaround for custom aggregate which would need "internal" as statetype
Next
From: Geoffrey
Date:
Subject: Re: trigger firing order