[
https://issues.apache.org/jira/browse/CALCITE-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682354#comment-17682354
]
Julian Hyde commented on CALCITE-5509:
--------------------------------------
Calcite allows implicit conversion of strings to date-times, even if they are
not literals. So we should be good.
If a function argument that is being implicitly converted is a literal, Calcite
should be able to use constant reduction at compile time, to convert the
automatically-added {{CAST}} to a literal of the target type. For example, if
{{f}} has type {{f(DATE, INTEGER)}} then {{f('2023-01-30', i)}} implicitly
becomes {{f(CAST('2023-01-30' AS DATE)), i)}} and that is constant-reduced to
{{f(DATE '2023-01-30', i)}}.
If function {{g}} has overloads {{g(VARCHAR)}} and {{g(DATE)}} then
{{g('2023-01-30')}} will resolve to the {{VARCHAR}} variant, because that
requires fewer conversions.
If you can write any test cases that contradict what I've said above, please
provide them.
> Allow automatic type coercion for string literals in BigQuery functions
> -----------------------------------------------------------------------
>
> Key: CALCITE-5509
> URL: https://issues.apache.org/jira/browse/CALCITE-5509
> Project: Calcite
> Issue Type: Improvement
> Reporter: Will Noble
> Priority: Minor
>
> BigQuery allows string literals to be automatically coerced into
> {{{}TIMESTAMP{}}}, {{{}DATETIME{}}}, or {{DATE}} literals. See in the
> [docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical]:
> {quote}String literals in canonical date format also implicitly coerce to
> DATE type when used where a DATE-type expression is expected...
> String literals with the canonical datetime format implicitly coerce to a
> datetime literal when used where a datetime expression is expected...
> String literals with the canonical timestamp format, including those with
> time zone names, implicitly coerce to a timestamp literal when used where a
> timestamp expression is expected.
> {quote}
> We should make sure that the BQ library functions respect this type coercion
> in general. This only applies to literals; not string values in general. For
> example, {{'2023-01-30'}} can be coerced to a timestamp, datetime, or date,
> but {{SUBSTRING('x2023-01-30', 2)}} cannot.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
