[
https://issues.apache.org/jira/browse/CALCITE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3563:
------------------------------
Description:
Sub-task targets on following two kinds of issues.
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
(2)Type is assignable conceptually, but in the runtime phase, explicite cast is
still required.
For example, according to _*SqlTypeAssignmentRules*_, *_ST_MakePoint(Decimal,
Decimal)_* also accepts operands with (_Integer_, _Decimal_) types, because
Decimal is assignable from Integer.
{code:java}
@Test public void test1() {
final String sql = "SELECT ST_MakePoint(1, 2.1)";
CalciteAssert.that()
.with(CalciteAssert.Config.GEO)
.query(sql)
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}
{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
applicable constructor/method found for actual parameters "int,
java.math.BigDecimal"; candidates are: "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal, java.math.BigDecimal)", "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
> Convert function operand type to match implementation if necessary in runtime
> -----------------------------------------------------------------------------
>
> Key: CALCITE-3563
> URL: https://issues.apache.org/jira/browse/CALCITE-3563
> Project: Calcite
> Issue Type: Sub-task
> Components: core
> Reporter: Feng Zhu
> Assignee: Feng Zhu
> Priority: Major
>
> Sub-task targets on following two kinds of issues.
>
> (1)Validation phase allows a wide range of operand types, but the runtime
> implementation does not cover all cases.
> For example, _*SqlFunction(MOD)*_ adopts
> _*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
> {code:java}
> @Test public void test0() {
> final String sql = "SELECT mod(12.5, cast(1 as bigint))";
> CalciteAssert.that()
> .query(sql)
> .returns("EXPR$0=0.5\n");
> }{code}
> We will get:
> {code:java}
> java.lang.RuntimeException: while resolving method 'mod[class
> java.math.BigDecimal, long]' in class class
> org.apache.calcite.runtime.SqlFunctions
> at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
> at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
>
> (2)Type is assignable conceptually, but in the runtime phase, explicite cast
> is still required.
> For example, according to _*SqlTypeAssignmentRules*_,
> *_ST_MakePoint(Decimal, Decimal)_* also accepts operands with (_Integer_,
> _Decimal_) types, because Decimal is assignable from Integer.
> {code:java}
> @Test public void test1() {
> final String sql = "SELECT ST_MakePoint(1, 2.1)";
> CalciteAssert.that()
> .with(CalciteAssert.Config.GEO)
> .query(sql)
> .returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
> }
> {code}
> We will get:
> {code:java}
> org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
> applicable constructor/method found for actual parameters "int,
> java.math.BigDecimal"; candidates are: "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal, java.math.BigDecimal)", "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal)"
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
> at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
