[
https://issues.apache.org/jira/browse/CALCITE-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5882:
------------------------------------
Labels: pull-request-available (was: )
> 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
> Priority: Minor
> Labels: pull-request-available
>
> 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)
