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 2016/10/10 19:46:20 UTC

[jira] [Commented] (CALCITE-1426) Support customized star expansion in RelDataType

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

Julian Hyde commented on CALCITE-1426:
--------------------------------------

See my comments on PHOENIX-3557. Let's reach consensus there before we start proposing Calcite API changes here.

> Support customized star expansion in RelDataType
> ------------------------------------------------
>
>                 Key: CALCITE-1426
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1426
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Maryann Xue
>            Assignee: Maryann Xue
>              Labels: phoenix
>             Fix For: 1.11.0
>
>
> This is to support PHOENIX-3357. Phoenix allows users to define columns in arbitrary order regardless of their column families, for example,
> {code}
> CREATE TABLE t
>   (a_string varchar not null, cf1.a integer, cf1.b varchar, col1 integer, cf2.c varchar, cf2.d integer, col2 integer
>   CONSTRAINT pk PRIMARY KEY (a_string))
> {code}
> , in which columns from the same family (i.e., col1 and col2 from the default column family) are not necessarily adjacent to each other.
> As a result, when we return row type for a PhoenixTable, we re-order the columns in order to fit them into the two-level column structure. This works fine in most cases except when:
> 1) "upsert into t ..." would require a different row type even after flattening (we do not have flattening so far, still need to implement CALCITE-1425).
> 2) select * from t would return a different column order.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)