[
https://issues.apache.org/jira/browse/CALCITE-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16782318#comment-16782318
]
Juhwan Kim commented on CALCITE-2888:
-------------------------------------
To be specific, suppose we have two filters and want to check if one filter
implies another where one filter is between '1900-01-01'(as date) to
'1900-01-03' and another filter is between '1900-01-01' to '1900-01-02'. If the
column we have is VARCHAR and if it has cast to DATE, then this is a valid
expression, and hence the first filter implies the second filter. However,
current implies call gives a runtime error.
The way I understood about implies call was 'given two filters(first and
second), returns whether first implies second'. In the optimal case, this
should return true whatever goes inside the filter as long as it is supported
by execution engine. So, I think this is an enhancement.
For example, if we have a simple divide function that returns a doulbe value
given two integers, then handling zero divisor should be done within the
function. Allowing runtime error to be thrown expecting that users would call
it without zero divisor doesn't seem right to me.
> Enhance RexImplicationChecker to better handle filters with CAST
> ----------------------------------------------------------------
>
> Key: CALCITE-2888
> URL: https://issues.apache.org/jira/browse/CALCITE-2888
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Juhwan Kim
> Assignee: Juhwan Kim
> Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I saw some cases where RexImplicationChecker gave an AssertionError when CAST
> was involved in the filters.
> For example, if a filter is
> '>(CAST(SOME_VHARCHAR_INPUT_REF, DATE), SOME_DATE_LITERAL)',
> currently, it removes CAST first and tries to convert DATE literal to VARCHAR
> type,
> which is not supported, and runtime AssertionError is thrown during
> implication checking.
> I think the issue can be solved by using RexExecutor's reduce function before
> removing cast from literal side. Also, allowing other implementations of
> RexExecutor would make it more flexible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
