You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@calcite.apache.org by "Chunhui Shi (JIRA)" <ji...@apache.org> on 2018/05/01 02:45:00 UTC

[jira] [Commented] (CALCITE-2159) UNNEST to support 'ANY' type

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

Chunhui Shi commented on CALCITE-2159:
--------------------------------------

Thank you Julian. I have addressed your concern. Could you take another look?

> UNNEST to support 'ANY' type
> ----------------------------
>
>                 Key: CALCITE-2159
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2159
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Chunhui Shi
>            Assignee: Julian Hyde
>            Priority: Major
>
> Not all data source has type information about the input of UNNEST during parsing stage. In Drill, if we want to support UNNEST(table.column) syntax for a document with nested structure, for now, these two things will happen:
> SqlUnnestOperator.inferReturnType will use unknown operand's type 'ANY' so isStruct will be false, thus the the following code will hit NULL reference.
>  
> Another issue is, Should UnnestnameSpace.getTable return a table so when other parts of the query tried to refer to some columns coming out of UNNEST, we know the query is asking for a column from the table, so the parser could add the column to the RowType of UNNEST? An example query is like this:
> SELECT AVG(o.o_amount) AS avg_orders FROM  UNNEST(c.orders) AS o
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)