Andres Freund <[email protected]> writes:
> Seems like if we do this - and I think we should - we should go broader than
> just doing this for int8[]. So yea, let's do it for float8 too.
> I think it might make sense to have an opr_sanity.sql check that verifies that
> we don't add new builtin aggregates that have an array transition state. Or
> perhaps even more strictly, test that aggregates either have an internal
> transition state, or the argument type's (for stuff like min/max).
On reflection, I'm not sure that such a policy is a win. If you go
with an internal-type transition state, then (if you want parallel
aggregation support) you need serialize/deserialize functions, and
I think also some other stuff that comes for free if the transition
state is a real SQL type. So this is not so much a clear win as
a tradeoff of which code you want to write.
regards, tom lane
