[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuzhao Chen updated CALCITE-2302:
---------------------------------
Description:
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 is design doc:
[https://docs.google.com/document/d/1g2RUnLXyp_LjUlO-wbblKuP5hqEu3a_2Mt2k4dh6RwU/edit?usp=sharing]
This is the conversion types mapping:
was:
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.
> 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 is design doc:
> [https://docs.google.com/document/d/1g2RUnLXyp_LjUlO-wbblKuP5hqEu3a_2Mt2k4dh6RwU/edit?usp=sharing]
>
> This is the conversion types mapping:
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
