[jira] [Created] (CALCITE-5882) Compile-time evaluation of SPLIT function returns incorrect result

[Mihai Budiu (Jira)]

Mihai Budiu created CALCITE-5882:
------------------------------------

             Summary: Compile-time evaluation of SPLIT function returns 
incorrect result
                 Key: CALCITE-5882
                 URL: https://issues.apache.org/jira/browse/CALCITE-5882
             Project: Calcite
          Issue Type: Bug
          Components: core
    Affects Versions: 1.35.0
            Reporter: Mihai Budiu


The compile-time evaluation of SPLIT functions produces wrong results. Here is 
an example test for RelOptRulesTest:
{code:java}
@Test public void testSplit2() {
    final String query = "select split('1|2|3', '|')";
    sql(query)
        .withFactory(
            t -> t.withOperatorTable(opTab ->
                SqlLibraryOperatorTableFactory.INSTANCE.getOperatorTable(
                    SqlLibrary.BIG_QUERY))) // needed for SPLIT function
        .withRule(CoreRules.PROJECT_REDUCE_EXPRESSIONS)
        .check();
  }
{code}

The result is expected to be an ARRAY containing strings '1', '2', '3', but the 
result is:

{code}
LogicalProject(EXPR$0=[ARRAY('1    ', '2    ', '3    ')])
  LogicalValues(tuples=[[{ 0 }]])
{code}

This probably happens because the type inference rule for the SPLIT operator is 
(SqlLibraryOperators.java):

{code:java}
 @LibraryOperator(libraries = {BIG_QUERY})
  public static final SqlFunction SPLIT =
      SqlBasicFunction.create("SPLIT",
          ReturnTypes.ARG0
              .andThen(SqlLibraryOperators::deriveTypeSplit)
              .andThen(SqlTypeTransforms.TO_ARRAY),
          ...
{code}

Thus, when ARG0 is CHAR(4) the return type is also inferred to be CHAR(4).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)