[
https://issues.apache.org/jira/browse/CALCITE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15576537#comment-15576537
]
Maryann Xue commented on CALCITE-1426:
--------------------------------------
I have also started to look at CALCITE-1425, which is related to the "insert"
part of this issue. It would seem a little bit unnatural to have the INSERT
support multiple-level column names, and also TableModify.getUpdateColumnList()
would have to return something different from a list of strings.
> Support customized star expansion in Table
> ------------------------------------------
>
> 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)
