Stephen Frost <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly