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/05/01 23:04:00 UTC
[jira] [Resolved] (CALCITE-2159) UNNEST to support 'ANY' type
[ https://issues.apache.org/jira/browse/CALCITE-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Hyde resolved CALCITE-2159.
----------------------------------
Resolution: Fixed
Fix Version/s: 1.17.0
Fixed in [c3f2705f|http://git-wip-us.apache.org/repos/asf/calcite/commit/c3f2705f]; thanks for the PR, [~cshi]!
> 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
> Fix For: 1.17.0
>
>
> 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)