Details
Description
The purpose is to return correct sum result when the number goes beyond its type limitation. Currently Calcite behaves "type sum( x ) = type x", so if the sum overflows, user get negative result.
Traditional SQL engines all expand the sum return type though in different ways.
From Julian Hyde, Aug 11:
Postgres return type is "bigint for smallint or int arguments, numeric for bigint arguments, otherwise the same as the argument data type” [ http://docs.oracle.com/database/121/SQLRF/functions196.htm#i89126 ]
SQL Server return type is int for tinyint, smallint or int; bigint for bigint [ http://public.dhe.ibm.com/ps/products/db2/info/vr101/pdf/en_US/DB2SQLRefVol1-db2s1e1011.pdf ].
I can see your point that “User demands the correct sum result”. But I’d also be pissed with Postgres if it returned a numeric (arbitrary precision) result when I am summing a bigint value. So I don’t think we’re going to please everyone.
I think the solution is to add the policy to derive SUM’s return type to as a new method to RelDataTypeSystem. Then Kylin can supply its own.
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Maryann Xue - this is the JIRA that will help make our SUM aggregation to work, since we coerce to a long any sum over integer numbers.