Re: array_accum aggregate

Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>> It looks like it should work to have just one polymorphic aggregate
>>> definition, eg, array_accum(anyelement) returns anyarray.
>
>> I was hoping to do that, but since it's an aggregate the ffunc format is
>> pre-defined to require accepting the 'internal state' and nothing else,
>> and to return 'anyelement' or 'anyarray' one of the inputs must be an
>> 'anyelement' or 'anyarray', aiui.
>
> Hmm ... I hadn't been thinking about what the state type would need to
> be, but certainly "bytea" is a lie given what you're really doing.
> We've run into this same problem in contrib/intagg: sometimes you'd like
> to use a state data structure that isn't any regular SQL datatype, and
> in particular isn't just a single blob of memory. That's a problem from
> nodeAgg's point of view because it expects to be responsible for copying
> the state value from one context to another. Don't have an immediate
> idea for a solution ...

I used an int8 as state type for an implementation of a kind of
array_accum_unique aggregate. I know that it's a ugly hack, but
it has been running on a production machine for months now, without
a problem...

The memory is alloc'd from the aggcontext, btw.

Note that I only use this aggregate in one particular query -
so there might be problems with my approach that just don't
manifest in my particular situation. For example, the aggregate
is used only on a table that is never updated, and it is only
used in select queries. So there might be problems if the executor
decides that it has to restart a query...

greetings, Florian Pflug