[
https://issues.apache.org/jira/browse/CALCITE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14359304#comment-14359304
]
Julian Hyde commented on CALCITE-613:
-------------------------------------
Ah yes. I had forgotten about MySQL needed to use concat.
As part of this task, we should decide and document which implicit type
conversions are allowed. It would seem bad if we treat literals differently
than other expressions, or worse if we treat literals differently based on
their content (e.g. "this string looks like a number, so let's implicitly
convert it to a number")
Oracle seems to implicitly convert strings to dates and numerics (see
http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements002.htm#g195937
Table 2-10 Implicit Type Conversion Matrix), which makes me happier that it is
reasonable for Calcite to do so. One of their examples: {code}SELECT last_name
FROM employees
WHERE hire_date = '03-MAR-97';{code}
We should also track https://issues.apache.org/jira/browse/DRILL-2443, which
describes Drill's conversion rules (less applicable, because these rules are
applied dynamically not statically).
> Literals need to be treated more flexible
> -----------------------------------------
>
> Key: CALCITE-613
> URL: https://issues.apache.org/jira/browse/CALCITE-613
> Project: Calcite
> Issue Type: Bug
> Reporter: Sean Hsuan-Yi Chu
> Assignee: Julian Hyde
>
> In relational DB such as Postgres, this query works fine.
> "select ... from ... where column (INT type) between '10' and '11'"
> Calcite blocks this query early by the fact that data types "char" &
> "integer" are not directly compatible. However, this is very common for
> people to filter columns with date types. For example,
> "...where date between '1911-01-01' and '1911-01-02' "
> To relax this type check when comparing with literals can help improve
> usability.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
