[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913576#comment-16913576
]
Julian Hyde edited comment on CALCITE-2302 at 8/22/19 6:23 PM:
---------------------------------------------------------------
I just noticed that we have {{RelDataTypeSystem.deriveDecimalDivideType}}
already. Suppose that method says that "9/2 should return DOUBLE". Then the
result should be the most accurate value that fits within DOUBLE, i.e. 4.5, not
4.0.
Don't think of it as integer division followed by a cast to DOUBLE i.e.
"CAST((9 / 2) AS DOUBLE)".
Also don't think of it as implicitly converting the arguments, i.e. "CAST(9 AS
DOUBLE) / CAST(2 AS DOUBLE)".
I think of it as defining "/" as an operator that takes two INTEGER arguments
and returns a DOUBLE (it would be expressed in Java as "double myDivide(int
arg1, int arg2)") that does all of that atomically, and produces the most
accurate result it can.
If you agree with this, do you think that we could leverage the existing
{{RelDataTypeSystem.deriveDecimalDivideType}} method, and we can get the
behavior you want without adding any methods to {{SqlConformance}}.
was (Author: julianhyde):
I just noticed that we have {{RelDataTypeSystem.deriveDecimalDivideType}}
already. Suppose that method says that "9/2 should return DOUBLE". Then the
result should be the most accurate value that fits within DOUBLE, i.e. 4.5, not
4.0.
Don't think of it as integer division followed by a cast to DOUBLE i.e.
"CAST((9 / 2) AS DOUBLE)".
Also don't think of it as implicitly converting the arguments, i.e. "CAST(9 AS
DOUBLE) / CAST(2 AS DOUBLE)".
I think of it as defining "/" as an operator "double myDivide(int arg1, int
arg2)".
If you agree with this, do you think that we could leverage the existing
{{RelDataTypeSystem.deriveDecimalDivideType}} method, and we can get the
behavior you want without adding any methods to {{SqlConformance}}.
> 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)
