Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-5811

Error messages produced for constant out-of-bounds arguments are confusing



    • Bug
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 1.34.0
    • 1.37.0
    • None


      Supplying arguments that are out-of-bounds for functions can produce uninformative messages. Consider this test case that can be added to SqlOperatorTest.checkSubstringFunction():

          f.checkString("substring('abc' from 2 for 2147483650)",
              "bc", "VARCHAR(3) NOT NULL");

      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:

      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

      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.





            Unassigned Unassigned
            mbudiu Mihai Budiu
            0 Vote for this issue
            4 Start watching this issue