On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina <drfar...@acm.org> wrote: > SUM(int2) => int4 > SUM(int4) => int8 > SUM(int8) => numeric > > Some weaknesses: > > SUM, of any precision, assumes that the precision being accumulated > into (which is also the return-precision) is enough to avoid overflow. > This is generally the case, but there's no reason why it *must* be > true. I'm especially looking at the int2 to int4 conversion. One could > imagine a more interesting scenario where overflow behavior could > occur much more easily.
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. int4 doesn't seem like as realistic a problem since it would take 4 billion rows and the performance penalty for using numeric would be much higher. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
