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

On 05/09/2026 19:01, Tom Lane wrote:
> So in these bits:
>
> + /* This is the first non-null input. */
> if (PG_ARGISNULL(0))
> - {
> - /* No non-null input seen so far... */
>
> the replacement comment is badly placed.

Fixed. I'm still not entirely sure where one-line comments like this should go —
I've seen them both right before the if and inside the block. It's probably
obvious to native speakers, but it leaves me a bit confused.

>
> At a less nit-picky level:
>
> * In the avg_accum functions, we can argue about how likely it
> is that we'd reach overflow of the "sum" fields, but it is completely
> insane to expend cycles and code complexity to check for overflow of
> the "count" fields. If you can reach 2^63 by repeated addition of 1
> within the lifetime of a PG database, then we have got far worse
> problems, eg with WAL LSN overflow.

Ok, fixed.

>
> * PG_RETURN_INPUT is not laid out per our usual conventions.
> If you need a do/while wrapper, start it on the next line.

Done

> * I would not include one single one of these test cases.
> They are not worth the development effort nor the forevermore
> test runtime cost, especially since they are testing faked-up
> scenarios.

Removed. Adding a regression test alongside a bug fix is just my default habit,
so I followed it here without thinking it through - happy to drop them.

--
regards, Andrei Lepikhov,
pgEdge