Re: array_accum aggregate

Stephen Frost <sfrost@snowman.net> writes:
>   Long story short, I set out to build a faster array_accum.  Much to my
>   suprise and delight, we already *had* one.  accumArrayResult() and
>   makeArrayResult()/construct_md_array() appear to do a fantastic job.
>   I've created a couple of 'glue' functions to expose these functions so
>   they can be used in an aggregate.  I'm sure they could be improved
>   upon and possibly made even smaller than they already are (90 lines
>   total for both) but I'd like to throw out the idea of including them
>   in core.  The aggregate created with them could also be considered for
>   inclusion though I'm less concerned with that.

Since you've set up the functions to only be usable inside an aggregate,
I don't see much of a reason why we wouldn't provide the aggregate too.
It looks like it should work to have just one polymorphic aggregate
definition, eg, array_accum(anyelement) returns anyarray.

As far as coding style goes, you're supposed to use makeArrayResult()
with accumArrayResult(), not call construct_md_array() directly.  And
copying the ArrayBuildState around like that is just plain bizarre...

Does the thing work without memory leakage (for a pass-by-ref datatype)
in a GROUP BY situation?
        regards, tom lane