[
https://issues.apache.org/jira/browse/SPARK-59988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Sadikov updated SPARK-59988:
---------------------------------
Description:
Calling to_timestamp (or try_to_timestamp) with a numeric first argument and a
format string fails during analysis with an INTERNAL_ERROR (SQLSTATE XX000)
instead of a user-facing type error:
{code:java}
SELECT to_timestamp(20201231, 'yyyyMMdd');{code}
{noformat}
[INTERNAL_ERROR] Cannot resolve the runtime replaceable expression
"to_timestamp(20201231, yyyyMMdd)". The replacement is unresolved: ...
{noformat}
The same happens for BIGINT, DECIMAL, DOUBLE etc. inputs, in both ANSI and
non-ANSI mode, and for try_to_timestamp.
{*}Root cause{*}:
ParseToTimestamp is a RuntimeReplaceable whose inputTypes accept NumericType
whenever the target type is TimestampType. That is only valid for the no-format
path, where the replacement is a Cast. When a format is given, the replacement
is GetTimestamp, whose inputTypes do not accept numeric inputs. The wrapper
therefore reports itself as resolved, type coercion never sees the replacement,
and CheckAnalysis hits its "replacement is unresolved" internal error guard.
Expected:
a DATATYPE_MISMATCH.UNEXPECTED_INPUT_TYPE error pointing at the first argument.
Numeric input without a format (e.g. to_timestamp(1)) should keep working as
before.
> to_timestamp with a numeric input and a format fails with INTERNAL_ERROR
> instead of DATATYPE_MISMATCH
> -----------------------------------------------------------------------------------------------------
>
> Key: SPARK-59988
> URL: https://issues.apache.org/jira/browse/SPARK-59988
> Project: Spark
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 4.3.0, 4.4.0
> Reporter: Ivan Sadikov
> Priority: Minor
>
> Calling to_timestamp (or try_to_timestamp) with a numeric first argument and
> a format string fails during analysis with an INTERNAL_ERROR (SQLSTATE XX000)
> instead of a user-facing type error:
> {code:java}
> SELECT to_timestamp(20201231, 'yyyyMMdd');{code}
> {noformat}
> [INTERNAL_ERROR] Cannot resolve the runtime replaceable expression
> "to_timestamp(20201231, yyyyMMdd)". The replacement is unresolved: ...
> {noformat}
> The same happens for BIGINT, DECIMAL, DOUBLE etc. inputs, in both ANSI and
> non-ANSI mode, and for try_to_timestamp.
> {*}Root cause{*}:
> ParseToTimestamp is a RuntimeReplaceable whose inputTypes accept NumericType
> whenever the target type is TimestampType. That is only valid for the
> no-format path, where the replacement is a Cast. When a format is given, the
> replacement is GetTimestamp, whose inputTypes do not accept numeric inputs.
> The wrapper therefore reports itself as resolved, type coercion never sees
> the replacement, and CheckAnalysis hits its "replacement is unresolved"
> internal error guard.
> Expected:
> a DATATYPE_MISMATCH.UNEXPECTED_INPUT_TYPE error pointing at the first
> argument. Numeric input without a format (e.g. to_timestamp(1)) should keep
> working as before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
