[ https://issues.apache.org/jira/browse/CALCITE-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jiajun Xie resolved CALCITE-5811. --------------------------------- Resolution: Fixed > Error messages produced for constant out-of-bounds arguments are confusing > -------------------------------------------------------------------------- > > Key: CALCITE-5811 > URL: https://issues.apache.org/jira/browse/CALCITE-5811 > Project: Calcite > Issue Type: Bug > Affects Versions: 1.34.0 > Reporter: Mihai Budiu > Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > Supplying arguments that are out-of-bounds for functions can produce > uninformative messages. Consider this test case that can be added to > SqlOperatorTest.checkSubstringFunction(): > {code:java} > f.checkString("substring('abc' from 2 for 2147483650)", > "bc", "VARCHAR(3) NOT NULL"); > {code} > The signature of the substring function requires int arguments. The constant > 2147483650 is out of bounds for an integer. This causes the test to fail with > the following exception: > {code:java} > Error while executing SQL "values (substring('abc' from 2 for 2147483650))": > Unable to implement EnumerableCalc(expr#0=[{inputs}], expr#1=['abc'], > expr#2=[2], expr#3=[2147483650:BIGINT], expr#4=[SUBSTRING($t1, $t2, $t3)], > EXPR$0=[$t4]): rowcount = 1.0, cumulative cost = {2.0 rows, 7.0 cpu, 0.0 io}, > id = 153424 > EnumerableValues(tuples=[[{ 0 }]]): rowcount = 1.0, cumulative cost = {1.0 > rows, 1.0 cpu, 0.0 io}, id = 153408 > {code} > I suspect this happens because of a combination of features: > - type inference does not reject the call to substring, although the > inferred type of the argument is probably bigint > - an attempt to evaluate the constant function fails because of some overflow > - the detailed exception about the overflow is lost when handling the error > I suspect this is a deeper problem which may affect all functions, and it is > really about type inference and implicit cast insertion. > I can imagine two possible implementation strategies: > - Postgres rejects such a call because the substring function cannot take a > bigint argument > - The compiler could add an implicit cast from bigint to int, which should > at least give a warning because the value is too large to fit in an integer > Both these solutions would avoid a crash in the expression evaluation. I > personally do not yet understand well enough the type inference mechanisms in > Calcite to propose a solution. > To make matters worse, some SQL dialects have substring functions with bigint > arguments. In this case there should be two different substring functions, > with different signatures. > This issue surfaced during a discussion for > [https://github.com/apache/calcite/pull/3286,] and is related to > https://issues.apache.org/jira/browse/CALCITE-5810. > -- This message was sent by Atlassian Jira (v8.20.10#820010)