[jira] [Created] (CALCITE-3513) Unify TableFunction implementor's NullPolicy and its beheavior

["Feng Zhu (Jira)" <ji...@apache.org>]

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)