Feng Zhu created CALCITE-3513: --------------------------------- Summary: Unify TableFunction implementor's NullPolicy and its beheavior Key: CALCITE-3513 URL: https://issues.apache.org/jira/browse/CALCITE-3513 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.21.0 Reporter: Feng Zhu Assignee: Feng Zhu
*Example:* TableFunctionTest#_testMultipleScannableTableFunctionWithNamedParameters_ {code:java} SQL3: select * from table("s"."Maze"(HEIGHT => 3, WIDTH => 5){code} *RelNode:* {code:java} EnumerableTableFunctionScan(invocation=[Maze(5, 3, DEFAULT())], rowType=[RecordType(VARCHAR(12) S)], elementType=[class [Ljava.lang.Object;]){code} *Code:* {code:java} public org.apache.calcite.linq4j.Enumerable bind(final org.apache.calcite.DataContext root) { return org.apache.calcite.runtime.Enumerables.slice0(org.apache.calcite.util.Smalls.MazeTable.generate2(5, 3, null).scan(root)); }{code} *Inconsistency:* Current now, _*TableFunctionImpl*_ creats its implementor with _*NullPolicy.ANY*_. If we follow the NullPolicy, it will generate null, rather than MazeTable.generate2(5, 3, null) It is not consistent with its definition. {code:java} /** If any of the arguments are null, return null. */ ANY{code} *Root Cause:* The issue is covered due to current codegen's mechanism, which combines a mutable states (_*NullAs*_) and *_NullPolicy_* together to determine the semantics for null checking. The implementation for example query actually do nothing about arguments' null checking. We can ignore this minor case at the moment, but the inconsistency prevents further optimizations. However, under current codegen implementation, I failed to figure out a test case to trigger the problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)