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

Maryann Xue commented on CALCITE-1426:
--------------------------------------

Yes, I agree that returning a list of expressions would be more general. But we 
need this interface in two places actually (just pushed another check-in to 
that branch before I saw this comment):
1. select * expansion
2. insert statement where target column list is not present
So if this interface is going to be used for 2) as well, expressions might not 
be desired. The reason why I used a list of strings was that I thought 
introducing SqlNode into the Table interface would seem a bit weird.
I'm fine with creating a sub-interface, though. Adding a method in SqlValidator 
also sounds fine, but it's only that Calcite has a few places that creates a 
SqlValidator instance.

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

Reply via email to