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

Julian Hyde commented on CALCITE-2302:
--------------------------------------

Calcite already does some implicit conversions. I agree we could do more.

Can you describe your use cases more fully?

> 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: Yuzhao Chen
>            Assignee: Julian Hyde
>            Priority: Major
>             Fix For: 1.17.0
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to