Re: Use int8 for int4/int2 aggregate accumulators?

I wrote:
> 3. As a separate proposal, we could change COUNT()'s running counter
> and output datatype from INT4 to INT8. This would make it a little
> slower but effectively overflow-proof.

> * Changing the output datatype of these operations --- especially COUNT
> --- might affect or even break applications. We got a few complaints,
> not many, about changing SUM() and AVG() from integer to NUMERIC output
> in 7.1. Changing SUM() to INT8 isn't likely to hurt anyone who survived
> that transition. But COUNT() is much more widely used and is more
> likely to affect people. Should we keep it at INT4 output to avoid
> compatibility problems?

I started working on this, and immediately got a pile of regression test
failures arising from:

create function rtest_viewfunc1(int4) returns int4 as
'select count(*) from rtest_view2 where a = $1'
language 'sql';
+ ERROR: return type mismatch in function: declared to return integer, returns bigint

While it'd be easy enough to change this regression test, this does
highlight my concern about changing the output type of COUNT().

I'm currently thinking that leaving the output type of COUNT() alone
might be the better part of valor. Possibly we could invent a separate
aggregate COUNT8() that returns int8, for use by them that need it.

Comments anyone? There wasn't a lot of discussion before...

regards, tom lane