[ https://issues.apache.org/jira/browse/CALCITE-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ruben Q L resolved CALCITE-5882. -------------------------------- Resolution: Fixed Fixed via [{{98f3048}}|https://github.com/apache/calcite/commit/98f3048fb1407e2878162ffc80388d4f9dd094b2] Thanks [~mbudiu] for the patch! > 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 > Fix For: 1.36.0 > > > 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)