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

From Tom Lane
Subject Re: Workaround for custom aggregate which would need "internal" as statetype
Date
Msg-id 1988.1144713863@sss.pgh.pa.us
Whole thread Raw
In response to Re: Workaround for custom aggregate which would need "internal"  ("Florian G. Pflug" <fgp@phlo.org>)
List 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 by date:

Previous
From: Geoffrey
Date:
Subject: Re: trigger firing order
Next
From: "Just Someone"
Date:
Subject: Re: How to find the latest (partial) WAL file