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

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

    [ https://issues.apache.org/jira/browse/CALCITE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019832#comment-17019832 ] 

Feng Zhu commented on CALCITE-3513:
-----------------------------------

[~vlsi], [~julianhyde], thanks a lot for your insightful feedback, I learned a lot. Jira is a better place for disscussion, so I move to here.
{quote}{{I think that table functions should behave the same as regular functions with regard to null arguments.}}

{{IIRC, there are annotations that you can put against a UDF to control whether a null argument means a null result.}}
{quote}
Current regular scalar function allows users to put annotations to control the null policy, but table function is always *_NullPolicy.ANY_*.
{quote}{{If so, those annotations should also apply to table functions.}}
{quote}
{{I agree with it, and this introduces the problem which I asked [~vlsi] for advice.}}

{{If we apply annotations, we need to handle the case of null result in Calcite internally.}}

{{Current implementation assumes table function's result is always null. The code below will results NPE exception.}}
org.apache.calcite.runtime.Enumerables.slice0(...result...);
{{It seems that an empty relation is more suitable.}}

> Unify TableFunction implementor's NullPolicy and its behavior
> -------------------------------------------------------------
>
>                 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: 3h 20m
>  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)