You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2018/01/31 05:07: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=16346267#comment-16346267 ] 

Julian Hyde commented on CALCITE-2159:
--------------------------------------

It sounds as if ANY is a poor fit for what you need. You need a record (struct) type that you can write fields into, and ANY is neither of those.

Are there any unit tests in Calcite for how Drill infers types based on usage? A good place to start might be to add test cases to those unit tests.

> 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)