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

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

Yeah, the assumption is that anything allocated in CurrentMemoryContext
other than the actual return value is just memory leakage, and it'll
automatically get thrown away.  You could probably use
aggstate->aggcontext, which is accessible to aggregate functions since
PG 8.1 (see the comments at the head of nodeAgg.c).

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Geoffrey
Дата:
Сообщение: Re: trigger firing order
Следующее
От: "Just Someone"
Дата:
Сообщение: Re: How to find the latest (partial) WAL file