Danny Chan commented on CALCITE-3250:

Thanks, Julian.

I add the SqlTypeNameSpec#deriveType(RelDataTypeFactory) mainly to adapter 
method SqlDataTypeSpec#deriveType(RelDataTypeFactory) which invoked by many 
codes that does not have the SqlValidator, #deriveType(RelDataTypeFactory) and 
#deriveType(SqlValidator) actually have different semantics, one can returns 
null but one never.

Personally i approve of your point to keep only one of them, but this may need 
more refactoring, i'm glad to to it if you think this is necessary.

I kind of disagree with the point that we should let the validator do the whole 
type inferring thing. In that case, we would have to do many code branch for 
different data types(basic type, collection type, row and UDT), which would 
bring in a mess of "if else" clause just like before this patch. The 
SqlTypeNameSpec actually have the full information to create a data type(the 
type name, precision/scale, charSet), the SqlDataTypeSpec now is a composition 
of SqlTypeNameSpec plus nullability.


> Support nested collection type for  SqlDataTypeSpec
> ---------------------------------------------------
>                 Key: CALCITE-3250
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3250
>             Project: Calcite
>          Issue Type: Sub-task
>          Components: core
>    Affects Versions: 1.20.0
>            Reporter: Danny Chan
>            Assignee: Danny Chan
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.21.0
>          Time Spent: 20m
>  Remaining Estimate: 0h
> According to SQL-2011, collection type can be nested:
> {code:sql}
> <array type> ::=
>   <data type> ARRAY [ <left bracket or trigraph> <maximum cardinality> <right 
> bracket or trigraph> ]
> <maximum cardinality> ::=
>   <unsigned integer>
> {code}
> *Example*:
> {code:sql}
> int array array;
> int multiset array;
> {code}

This message was sent by Atlassian JIRA

Reply via email to