array_agg (was Re: The Axe list)
2008/10/15 Ian Caulfield <ian.caulfield@gmail.com>:
I started to look at implementing array_agg by making the existing
intagg stuff more generic
... and here's what I've come up with.
I've currently implemented this as a contrib module to make it quicker
to develop/test.
The aggregate uses the same basic approach to memory management as
intagg, but instead of putting data into the lower bound, an extra
structure is placed just before the data, after the null bitmap. This
holds a copy of the typlen, typbyval and typalign, as well as a
pointer to the next (unaligned) free data byte. In order to avoid
breakage due to initial values being set in another aggregate, the
transition function will reject an array value where extra padding
isn't present before the data values.
The ORDER BY clause of array_agg isn't implemented - it seems that
this would work best as a generic solution to pass ordered data to
aggregates, and is beyond my ability to implement currently.
Ian
Attachments:
I've been taking a look at this as well and came up with a slightly
different approach. The attached patch is intended to go in core (not
contrib) and uses some array-construction facilities that already
exist in core. I'm not sure which approach is better, so I'll throw
this out there with yours for input...
...Robert
Attachments:
array_accum-v1.patchtext/x-diff; name=array_accum-v1.patchDownload+52-0
Ian Caulfield wrote:
2008/10/15 Ian Caulfield <ian.caulfield@gmail.com>:
I started to look at implementing array_agg by making the existing
intagg stuff more generic... and here's what I've come up with.
Going through the commit fest listings, I think we can safely omit this
patch and work out an in-core solution somewhere between the patches of
Robert Haas and Jeff Davis.