Julian Hyde commented on CALCITE-1426:

It's too intrusive to add a new method to Table. Can you create a sub-interface 

Having the method return lists of strings seems too closely fitted to Phoenix's 
requirements. (Phoenix is the only database I've ever heard of that has column 
families. If this is not useful beyond Phoenix maybe we should just add an 
{{expandStar}} method to the validator and let Phoenix override.) Could the 
method instead return a list of expressions and their aliases? That way we 
could model system columns, default columns, and other things. Or maybe the 
method could return a SqlNode that represents a query, e.g.

select k0, c1, f1.a0 as f1_a0, f2.a0 as f2_a0, f0.c0 f0_c0,
  f1.c0 as f1_c0, f1.c2 as f1_c2, f2.c3 as f2.c3
from t

and replace "from t" by "from (select k0 ... from t)" if a query requests star 
expansion. Obviously this is much more general but it means the feature is 
potentially useful for other than Phoenix. Note that it does save a *little* 
code in the validator, because the Table implementation will deal with creating 
SqlIdentifiers and deducing aliases.

> 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}
>   (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

Reply via email to