[
https://issues.apache.org/jira/browse/CALCITE-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813820#comment-17813820
]
Julian Hyde commented on CALCITE-6238:
--------------------------------------
Ideal would be a variation of the second: check that the argument is in range,
then cast to integer.
The third option would create lots of useless copy-pasted code. We know that
the {{BIGINT}} variant does not have different behavior from the {{INTEGER}} or
even {{SMALLINT}} variant. So we should be parsimonious, and just define the
function once. (Our parsimonious approach to strict functions has been very
successful – if we know that {{f(x, y)}} returns {{NULL}} if {{x}} or {{y}} are
null, we only implement {{f(int, int)}} and generate wrapper code to intercept
null values.)
> Exception while evaluating ROUND function
> -----------------------------------------
>
> Key: CALCITE-6238
> URL: https://issues.apache.org/jira/browse/CALCITE-6238
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.36.0
> Reporter: Mihai Budiu
> Priority: Minor
>
> The following test in CalciteSqlOperatorTest:
> {code:java}
> @Test void testRoundFunc() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("round(42, CAST(2 as BIGINT))", 42, "INTEGER NOT NULL");
> }
> {code}
> causes an exception; here is the relevant part of the stack trace:
> {code}
> java.sql.SQLException: Error while executing SQL "values (round(42, CAST(2 as
> BIGINT)))": Unable to implement EnumerableCalc(expr#0=[{inputs}],
> expr#1=[42], expr#2=[2:BIGINT], expr#3=[ROUND($t1, $t2)], EXPR$0=[$t3]):
> rowcount = 1.0, cumulative cost = {2.0 rows, 6.0 cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[{ 0 }]]): rowcount = 1.0, cumulative cost = {1.0
> rows, 1.0 cpu, 0.0 io}, id = 13
> ...
> Suppressed: java.lang.RuntimeException: while resolving method
> 'sround[int, long]' in class class org.apache.calcite.runtime.SqlFunctions
> at
> org.apache.calcite.adapter.enumerable.EnumUtils.call(EnumUtils.java:679)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodImplementor.call(RexImpTable.java:2818)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodImplementor.implementSafe(RexImpTable.java:2799)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3857)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3819)
> {code}
> And indeed, SqlFunctions does not have a function sround with this signature.
> There are several possible fixes:
> - reject calls to ROUND that have a BIGINT second argument
> - have the validator insert an implicit cast for the second argument to
> INTEGER
> - implement more Java versions of the SROUND function in SqlFunctions.
> Probably many more.
> Which one of these is the right one? I suspect this problem applies to other
> SQL functions as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
