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)
