* Tom Lane (tgl@sss.pgh.pa.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
