[
https://issues.apache.org/jira/browse/DRILL-8136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600953#comment-17600953
]
ASF GitHub Bot commented on DRILL-8136:
---------------------------------------
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1238561477
> @jnturton Do you think this should be included in the backport to stable?
My own thought is probably not since it changes the function matching
process and there isn't any clear bug that it fixes.
> 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)