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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Postgresql-General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Workaround for custom aggregate which would need "internal" as statetype
Date: 2006-04-11 00:04:23
Message-ID: 1988.1144713863@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Florian G. Pflug" <fgp(at)phlo(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Just Someone 2006-04-11 00:10:20 Re: How to find the latest (partial) WAL file
Previous Message Geoffrey 2006-04-10 23:59:34 Re: trigger firing order