Re: Workaround for custom aggregate which would need "internal"

Поиск
Список
Период
Сортировка
От Florian G. Pflug
Тема Re: Workaround for custom aggregate which would need "internal"
Дата
Msg-id 443AEF07.5090603@phlo.org
обсуждение исходный текст
Ответ на Re: Workaround for custom aggregate which would need "internal" as statetype  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Workaround for custom aggregate which would need "internal" as statetype  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Workaround for custom aggregate which would need "internal" as statetype
Следующее
От: Geoffrey
Дата:
Сообщение: Re: trigger firing order