[
https://issues.apache.org/jira/browse/CALCITE-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Nuyanzin closed CALCITE-5811.
------------------------------------
Resolved in release 1.37.0 (2024-05-06)
> 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)
