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

Danny Chan commented on CALCITE-2302:
-------------------------------------

[~julianhyde] Personally i propose to add this policy to SqlConformance, 
because it is very about the execution behavior of a SqlDialect, the 
RelDataTypeSystem defines some type deriving behaviors of the entire type 
system in methods like "deriveXXX", but strictly to say, "two integers division 
returns what kind of data" not only is relative with "what sql type we should 
return" but "what data we should return".

We can say that "9/2 should return double", then 4.5 and 4.0 can both be seen 
as double type. For an implicit type coercion, what we really changed is the 
runtime/execution behavior, not only the type inferring.

Another reason is that RelDataTypeSystem is about Calcite type system behaviors 
which are not designed pluggable for all kinds of SQL dialects.

> Implicit type cast support
> --------------------------
>
>                 Key: CALCITE-2302
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2302
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.17.0
>            Reporter: Danny Chan
>            Assignee: Danny Chan
>            Priority: Critical
>              Labels: pull-request-available
>             Fix For: 1.21.0
>
>          Time Spent: 7h 10m
>  Remaining Estimate: 0h
>
> Now many DBs have support implicit type cast, eg: SqlServer, Oracle, Hive.
> Implicit type cast is an useful function for many cases, So we should support 
> this.
> I checkout Calcite code and found that:
>  # Now we use a validator to validate our operands types[ through kinds of 
> namespaces and scopes ]
>  # Most of the validations will finally goes to
> {code:java}
> SqlOperator.validateOperands
> {code}
>  # which will use validation logic defined in corresponding 
> SqlOperandTypeChecker
> What i'm confused about is where should i put the implicit type cast logic 
> in? I figured out 2 ways:
>  # Supply a tool class/rules to add casts into a parsed SqlNode tree which 
> will then go through the validation logic later on.
>  # Unleash the validation logic in kinds of SqlOperandTypeChecker, then 
> modify the RelNode/RexNodes tree converted from a validated SqlNode tree to 
> add in casts through custom RelOptRules.
> So guys, which of the 2 ways should i go, or if there are better way to do 
> this?
> I need your help.
>  
> Updated 18-05-30:
> Hi guys, i have made a PR in 
> [CALCITE-2302|https://github.com/apache/calcite/pull/706]
> This is design doc: [Calcite Implicit Type Cast 
> Design|https://docs.google.com/document/d/1g2RUnLXyp_LjUlO-wbblKuP5hqEu3a_2Mt2k4dh6RwU/edit?usp=sharing].
> This is the conversion types mapping: [Conversion Types 
> Mapping|https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing].
> I really appreciate your suggestions, thx.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Reply via email to