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)