[
https://issues.apache.org/jira/browse/CALCITE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-845:
--------------------------------
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 [~julianhyde], Aug 11:
{quote}
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.
{quote}
was:
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 <[email protected]> Aug 11
"""
Postgres return type is "bigint for smallint or int arguments, numeric for
bigint arguments, otherwise the same as the argument data type”[1]
SQL Server return type is int for tinyint, smallint or int; bigint for
bigint[2].
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.
"""
> Derive SUM’s return type by a customizable policy
> -------------------------------------------------
>
> Key: CALCITE-845
> URL: https://issues.apache.org/jira/browse/CALCITE-845
> Project: Calcite
> Issue Type: Bug
> Reporter: liyang
> Assignee: Julian Hyde
>
> 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 [~julianhyde], Aug 11:
> {quote}
> 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.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
