From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: array_accum aggregate |
Date: | 2006-10-06 21:29:05 |
Message-ID: | 6253.1160170145@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2006-10-06 21:40:42 | Re: 8.2 translation status? |
Previous Message | Bruno Wolff III | 2006-10-06 21:17:34 | Re: pg_dump exclusion switches and functions/types |