Re: array_accum aggregate

What is the status of this feature addition?

---------------------------------------------------------------------------

Stephen Frost wrote:
-- Start of PGP signed section.
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > (However, now that we support nulls in arrays, meseems a more consistent
> > definition would be that it allows null inputs and just includes them in
> > the output. So probably you do need it non-strict.)
>
> This was my intention.
>
> > I'm inclined to think that this example demonstrates a deficiency in the
> > aggregate-function design: there should be a way to declare what we're
> > really doing. But I don't know exactly what that should look like.
>
> I agree and would much rather have a clean solution which works with the
> design than one which has to work outside it. When I first was trying
> to decide on the state-type I was looking through the PG catalogs for
> essentially a "complex C type" which translated to a void*. Perhaps
> such a type could be added. Unless that's considered along the lines of
> an 'any' type it'd cause problems for the polymorphism aspect.
>
> Another alternative would be to provide a seperate area for each
> aggregate to put any other information it needs. This would almost
> certainly only be available to C functions but would essentially be a
> void* which is provided through the AggState structure but tracked by
> the aggregator routines and reset for each aggregate function being
> run. If that's acceptable, I don't think it'd be all that difficult to
> implement. With that, aaccum_sfunc and aaccum_ffunc would ignore the
> state variable passed to them in favor of their custom structure
> available through fcinfo->AggState (I expect they'd just keep the
> state variable NULL and be marked non-strict, or set it to some constant
> if necessary). The pointer would have to be tracked somewhere and then
> copied in/out on each call, but that doesn't seem too difficult to me.
> After all, the state variable is already being tracked somewhere, this
> would just sit next to it, in my head anyway.
>
> I've got some time this weekend and would be happy to take a shot at
> the second proposal if that's generally acceptable.
>
> Thanks,
>
> Stephen
-- End of PGP section, PGP failed!

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +