From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgresql-General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Workaround for custom aggregate which would need "internal" |
Date: | 2006-04-10 23:49:27 |
Message-ID: | 443AEF07.5090603@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Geoffrey | 2006-04-10 23:59:34 | Re: trigger firing order |
Previous Message | Tom Lane | 2006-04-10 23:29:32 | Re: Workaround for custom aggregate which would need "internal" as statetype |