Re: SUM(int2)/SUM(int4) do not detect overflow of the int8 accumulator

On Thu, Sep 03, 2026 at 09:48:31AM +0200, Andrei Lepikhov wrote:
> Two details make me think this deserves a fix rather than a documentation note:
>
> * For sum(int4) the answer depends on the plan. int4_sum has no overflow check,
> but the combine function is int8pl, which does. So the same query over the same
> data returns a wrapped negative number under a serial plan and can fail with
> "bigint out of range" under parallel aggregation.
>
> * avg(int4) is not even inconsistent - it is wrong either way. Both
> int4_avg_accum and int4_avg_combine add into state->sum unchecked, so no plan
> shape turns this into an error. The int2 variants behave the same.

It looks to me that you are making your point here, thanks. I can
fall behind that. Even if these functions are marked as internal, we
could still reach the overflows, and I don't find that cool, like you.

A custom aggregate could make the test cheaper and still available
without direct function calls, perhaps, for example with a sfunc =
int{2,4}_sum and an initcond at INT64_MIN/MAX?

Any thoughts or comments from others?
--
Michael