[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908903#comment-16908903
]
Danny Chan edited comment on CALCITE-2302 at 8/28/19 2:58 AM:
--
Thanks so much for your review [~hyuan] !
I have add a new SqlConformance for PostgreSql and SqlServer which seem the
only engine that returns integer for 2 integers division. I checked again for
the behavior:
* Hive and Spark all return double, Hive also have a "A DIV B" function to
return integer
* PostgreSql and SQL_SERVER returns integer.
* Mysql returns double while it has a DIV() function to return integer
* Oracle returns double, but have no function to return integer
was (Author: danny0405):
Thanks so much for your review [~hyuan] !
I have add a new SqlConformance for PostgreSql and SqlServer which seem the
only engine that returns integer for 2 integers division. I checked again for
the behavior:
* Hive and Spark all return double, Hive also have a "A DIV B" function to
return integer
* PostgreSql and SQL_SERVER returns integer.
* Mysql returns double while it has a DIV() function to return integer
* Oracle returns double, it also has a DIV() function to return integer
> 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: 7.5h
> 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)
[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914070#comment-16914070
]
Danny Chan edited comment on CALCITE-2302 at 8/28/19 1:32 AM:
--
I have made the latest change in commit
[94134d5|https://github.com/apache/calcite/pull/706/commits/94134d5dd6a9c38cc22ff74bdd05a31d76e41b29]
!
Instead of leveraging the existing RelDataTypeSystem.deriveDecimalDivideType
method, i add a new SqlReturnTypeInference named NUMERIC_QUOTIENT chained into
the exists return type inference of "DIVIDE" operator.
Also i modified the expression to make them returns double(2 QuidemTest changes
because of this change, their results become more accurate).
was (Author: danny0405):
I have made the latest change in commit
[7b03ac7|https://github.com/apache/calcite/pull/706/commits/7b03ac7f466c248a0765447ce4a18c9d9393aa95]
!
Instead of leveraging the existing RelDataTypeSystem.deriveDecimalDivideType
method, i add a new SqlReturnTypeInference named NUMERIC_QUOTIENT chained into
the exists return type inference of "DIVIDE" operator.
Also i modified the expression to make them returns double(2 QuidemTest changes
because of this change, their results become more accurate).
> 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: 7.5h
> 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)
[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914070#comment-16914070
]
Danny Chan edited comment on CALCITE-2302 at 8/24/19 2:31 AM:
--
I have made the latest change in commit
[7b03ac7|https://github.com/apache/calcite/pull/706/commits/7b03ac7f466c248a0765447ce4a18c9d9393aa95]
!
Instead of leveraging the existing RelDataTypeSystem.deriveDecimalDivideType
method, i add a new SqlReturnTypeInference named NUMERIC_QUOTIENT chained into
the exists return type inference of "DIVIDE" operator.
Also i modified the expression to make them returns double(2 QuidemTest changes
because of this change, their results become more accurate).
was (Author: danny0405):
I have made the latest change in commit
[7b03ac7|https://github.com/apache/calcite/pull/706/commits/7b03ac7f466c248a0765447ce4a18c9d9393aa95]
!
Instead of leveraging the existing RelDataTypeSystem.deriveDecimalDivideType
method, i add a new SqlReturnTypeInference named EXACT_INTEGER_QUOTIENT chained
into the exists return type inference of "DIVIDE" operator.
Also i modified the expression to make them returns double(2 QuidemTest changes
because of this change, their results become more accurate).
> 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)
[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913843#comment-16913843
]
Danny Chan edited comment on CALCITE-2302 at 8/23/19 3:46 AM:
--
Thanks, [~julianhyde] I kind of agree with your point that the "DIVIDE"
operator is the role to decide what kind of data it should return, not the
implicit type casts. Even though the implicit casts can implement as the same
behavior with configurable sql dialects.
Personally I have no strong objections on leverage the return type inferring of
RelDataTypeSystem.deriveDecimalDivideType method.
Let's give up the thoughts that we should keep the "DIVIDE" synced and
configurable with different sql dialects.
was (Author: danny0405):
Thanks, [~julianhyde] I kind of agree with your point that the "DIVIDE"
operator is the role to decide what kind of data it should return, not the
implicit type casts. Even though the implicit casts can implement as the same
behavior with configurable sql dialects.
Personally I have no strong objections on leverage the return type inferring of
RelDataTypeSystem.deriveDecimalDivideType method, just one question:
# How to support different sql dialects ? Because PostgreSQL and SQL-SERVER
return integer and the others return double ? Especially for our JDBC
connectors, do we need add a control flag or something ?
> 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)
[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910144#comment-16910144
]
Danny Chan edited comment on CALCITE-2302 at 8/19/19 2:59 AM:
--
Thanks [~zabetak], most of the sql contexts that need implicit type coercion
are common in the popular DB engines, what we need to be caution is the
different behaviors of some cast cases. We can fix them for specific dialects
if we find any. But AFAIK, this kind of cases are really few.
Because almost all the DB engines that support implicit type coercion default
enable the casts, we should also follow this to default enable type coercion
for Calcite.
was (Author: danny0405):
Thanks [~zabetak], most of the sql contexts that need implicit type coercion
are common in the popular DB engines, what we need to be caution is the
different behaviors of some cast cases. We can fix them for specific dialects
if we find any. But AFAIK, this kind of cases are really few.
But because almost all the DB engines that support implicit type coercion
default enable the casts, we should also follow this to default enable type
coercion for Calcite.
> 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: 6.5h
> 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
(v7.6.14#76016)
[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908903#comment-16908903
]
Danny Chan edited comment on CALCITE-2302 at 8/19/19 2:55 AM:
--
Thanks so much for your review [~hyuan] !
I have add a new SqlConformance for PostgreSql and SqlServer which seem the
only engine that returns integer for 2 integers division. I checked again for
the behavior:
* Hive and Spark all return double, Hive also have a "A DIV B" function to
return integer
* PostgreSql and SQL_SERVER returns integer.
* Mysql returns double while it has a DIV() function to return integer
* Oracle returns double, it also has a DIV() function to return integer
was (Author: danny0405):
Thanks so much for your review [~hyuan] !
I have add a new SqlConformance for PostgreSql and SqlServer which seem the
only engine that returns integer for 2 integers division. I checked again for
the behavior:
* Hive and Spark all return double, Hive also have a "A DIV B" function to
return integer
* PostgreSql and SQL_SERVER returns integer.
* Mysql returns double while it has a DIV() function to return integer
> 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: 6.5h
> 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
(v7.6.14#76016)
[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910144#comment-16910144
]
Danny Chan edited comment on CALCITE-2302 at 8/19/19 2:52 AM:
--
Thanks [~zabetak], most of the sql contexts that need implicit type coercion
are common in the popular DB engines, what we need to be caution is the
different behaviors of some cast cases. We can fix them for specific dialects
if we find any. But AFAIK, this kind of cases are really few.
But because almost all the DB engines that support implicit type coercion
default enable the casts, we should also follow this to default enable type
coercion for Calcite.
was (Author: danny0405):
Thanks [~zabetak], most of the sql contexts that need implicit type coercion
are common in the popular DB engines, what we need to be caution is the
different behaviors of some cast cases. We can fix them for specific dialects
if we find any. But AFAIK, this kind of cases are really few.
I think we should keep the casts default enabled, which is also adopted by all
the other DB engines.
> 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: 6.5h
> 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
(v7.6.14#76016)
[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908903#comment-16908903
]
Danny Chan edited comment on CALCITE-2302 at 8/16/19 9:45 AM:
--
Thanks so much for your review [~hyuan] !
I have add a new SqlConformance for PostgreSql and SqlServer which seem the
only engine that returns integer for 2 integers division. I checked again for
the behavior:
* Hive and Spark all return double, Hive also have a "A DIV B" function to
return integer
* PostgreSql and SQL_SERVER returns integer.
* Mysql returns double while it has a DIV() function to return integer
was (Author: danny0405):
Thanks so much for your review [~hyuan] !
I have add a new SqlConformance for PostgreSql and SqlServer which seem the
only engine that returns integer for 2 integers division. I checked again for
the behavior:
* Hive and Spark all return double, Hive also have a "A DIV B" function to
returns integer
* PostgreSql and SQL_SERVER returns integer.
* Mysql returns double while it has a DIV() function to returns integer
> 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: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 6.5h
> 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
(v7.6.14#76016)
[jira] [Comment Edited] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907122#comment-16907122
]
Stamatis Zampetakis edited comment on CALCITE-2302 at 8/14/19 10:05 AM:
Hey [~hyuan], it seems that you reviewed the PR; is it ready to go (minus the
conflicts that can be resolved easily)? Will it make it for 1.21.0?
was (Author: zabetak):
Hey [~hyuan], it seems that you reviewed the PR; is it ready to go? Will it
make it for 1.21.0?
> 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: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 4h 40m
> 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
(v7.6.14#76016)
