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