Greg Stark <gsstark@mit.edu> writes:
> Fwiw I think he's right that sum(int2) should perhaps be redefined to
> return int8. As it stands all it would take is a 64k rows to
> potentially overflow. It's not super likely but it is plausible and
> the performance penalty to use int8 wouldn't be super big either.
It's not unreasonable. I think the performance penalty for int8 was
higher when that choice was made than it is now --- and in particular,
on a 64-bit machine it's now pretty much negligible.
On the other hand, you can always execute sum(foo::int4) if you need a
wider sum, just like the escape hatch if any of the other datatype
choices aren't working for you. It's not clear that we should force a
performance loss on people who don't need it (and I can't offhand recall
*ever* hearing a complaint about sum(int2) overflowing...)
I believe what the OP was arguing for was not so much this sort of
marginal tinkering as inventing a more general notion of "integer type"
that would avoid the whole issue. The problem with that is that we have
to work within the set of types specified by the SQL standard.
regards, tom lane