[
https://issues.apache.org/jira/browse/DRILL-8136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605164#comment-17605164
]
ASF GitHub Bot commented on DRILL-8136:
---------------------------------------
jnturton commented on code in PR #2638:
URL: https://github.com/apache/drill/pull/2638#discussion_r971630497
##########
exec/java-exec/src/main/java/org/apache/drill/exec/resolver/DefaultFunctionResolver.java:
##########
@@ -58,27 +56,20 @@ public DrillFuncHolder getBestMatch(List<DrillFuncHolder>
methods, FunctionCall
}
}
- if (bestcost < 0) {
+ if (bestcost == Float.POSITIVE_INFINITY) {
//did not find a matched func implementation, either w/ or w/o implicit
casts
//TODO: raise exception here?
return null;
- } else {
- if (AssertionUtil.isAssertionsEnabled() && bestMatchAlternatives.size()
> 0) {
- /*
- * There are other alternatives to the best match function which could
have been selected
- * Log the possible functions and the chose implementation and raise
an exception
- */
- logger.error("Chosen function impl: " + bestmatch.toString());
-
- // printing the possible matches
- logger.error("Printing all the possible functions that could have
matched: ");
- for (DrillFuncHolder holder: bestMatchAlternatives) {
- logger.error(holder.toString());
- }
+ }
+ if (bestMatchAlternatives.size() > 0) {
Review Comment:
@vvysotskyi do you think it would be better to introduce a deterministic way
of choosing between multiple functions of the same cost, so that query results
are consistent, or to raise an error? To me the first route seems better...
Footnotes. I think it will seldom be the case that two functions with equal
casting cost will be found, but nothing precludes it. As always users still
have the ability to use explicit casts to manually control which function is
used.
> Overhaul implict type casting logic
> -----------------------------------
>
> Key: DRILL-8136
> URL: https://issues.apache.org/jira/browse/DRILL-8136
> Project: Apache Drill
> Issue Type: Improvement
> Reporter: Esther Buchwalter
> Assignee: James Turton
> Priority: Minor
>
> The existing implicit casting system is built on simplistic total ordering of
> data types[1] that yields oddities such as TINYINT being regarded as the
> closest numeric type to VARCHAR or DATE the closest type to FLOAT8. This, in
> turn, hurts the range of data types with which SQL functions can be used.
> E.g. `select sqrt('3.1415926')` works in many RDBMSes but not in Drill while,
> confusingly, `select '123' + 456` does work in Drill. In addition the
> limitations of the existing type precedence list mean that it has been
> supplmented with ad hoc secondary casting rules that go in the opposite
> direction.
> This Issue proposes a new, more flexible definition of casting distance based
> on a weighted directed graph built over the Drill data types.
> [1]
> [https://drill.apache.org/docs/supported-data-types/#implicit-casting-precedence-of-data-types]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
