[
https://issues.apache.org/jira/browse/CALCITE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16977068#comment-16977068
]
Feng Zhu commented on CALCITE-3513:
-----------------------------------
Thanks [~julianhyde] , I agree with your points. Let's re-think about the case
for TableFunction.
I checked all tests when I digged into this part for codegen. Beside this one,
there is another case ({color:#FF0000}_*ROW*_{color}) with inconsistency.
*Query(in misc.q):*
{code:java}
select period("sqlDate", INTERVAL '1' YEAR) as p
from "everyTypes";
{code}
*RelNode:*
{code:java}
EnumerableCalc(expr#0..20=[{inputs}], expr#21=[12:INTERVAL YEAR],
expr#22=[ROW($t16, $t21)], P=[$t22])
EnumerableTableScan(table=[[s, everyTypes]]){code}
*Result:*
{code:java}
+------------+
| P |
+------------+
| {0, 12} |
| {null, 12} |
+------------+
{code}
*Inconsistency:*
In RexImpTable, we can find that the _*ROW*_ operator's NullPolicy is _ANY_
{code:java}
defineMethod(ROW, BuiltInMethod.ARRAY.method, NullPolicy.ANY);
{code}
According to this definition, the result should be
{code:java}
+------------+
| P |
+------------+
| {0, 12} |
| null |
+------------+
{code}
For this case, I think the right NullPolicy for _*ROW*_ should be _NONE_.
> 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
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *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)
