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
signature.asc
Description: PGP signature
