[
https://issues.apache.org/jira/browse/FLINK-21715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonard Xu updated FLINK-21715:
-------------------------------
Description:
The existed UDFs using `LocalDateTime` or `java.sql.Timestamp` as parameters
type, if the data type of parameter column in SQL changed from TIMESTAMP to
TIMESTAMP_LTZ, these UDFs must be rewritten, because TIMESTAMP_LTZ data type
does not support `LocalDateTime` or `java.sql.Timestamp` as conversion class.
The first approach is to support the two conversion classes for TIMESTAMP_LTZ
data type, to obtain the correct result, the local time zone information is
necessary when conversion happens between SQL internal data structure
`TimestampData` and external conversion class `LocalDateTime` or
`java.sql.Timestamp`.
In this approach, after a e2e POC, we found that there are more changes than we
thought before. It is difficult to cover with tests and it is easy to introduce
bugs.
Thus, to resolve the UDF compatibility issue, we consider support the implicit
cast conversion between timestamp and timestamp_ltz after some offline discuss
with [~jark] and [~ykt836],
This way is clean and lightweight way to resolve the UDF compatibility issue
and doesn't change any public interface as well. BTW the implicit cast
conversion is supported in Oracle[1]
[1]https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm
was:
The existed UDFs using `LocalDateTime` or `java.sql.Timestamp` as parameters
type, if the data type of parameter column in SQL changed from TIMESTAMP to
TIMESTAMP_LTZ, these UDFs must be rewritten, because TIMESTAMP_LTZ data type
does not support `LocalDateTime` or `java.sql.Timestamp` as conversion class.
The first approach is to support the two conversion classes for TIMESTAMP_LTZ
data type, to obtain the correct result, the local time zone information is
necessary when conversion happens between SQL internal data structure
`TimestampData` and external conversion class `LocalDateTime` or
`java.sql.Timestamp`.
In this approach, I made a POC, I found that there are more changes than we
thought before. It is difficult to cover with tests and it is easy to introduce
bugs.
Thus, to resolve the UDF compatibility issue, we consider support the
> Support implicit cast conversion between timestamp and timestamp_ltz
> ---------------------------------------------------------------------
>
> Key: FLINK-21715
> URL: https://issues.apache.org/jira/browse/FLINK-21715
> Project: Flink
> Issue Type: Sub-task
> Components: Table SQL / API, Table SQL / Runtime
> Reporter: Leonard Xu
> Assignee: Leonard Xu
> Priority: Major
>
> The existed UDFs using `LocalDateTime` or `java.sql.Timestamp` as parameters
> type, if the data type of parameter column in SQL changed from TIMESTAMP to
> TIMESTAMP_LTZ, these UDFs must be rewritten, because TIMESTAMP_LTZ data type
> does not support `LocalDateTime` or `java.sql.Timestamp` as conversion class.
>
> The first approach is to support the two conversion classes for
> TIMESTAMP_LTZ data type, to obtain the correct result, the local time zone
> information is necessary when conversion happens between SQL internal data
> structure `TimestampData` and external conversion class `LocalDateTime` or
> `java.sql.Timestamp`.
> In this approach, after a e2e POC, we found that there are more changes than
> we thought before. It is difficult to cover with tests and it is easy to
> introduce bugs.
>
> Thus, to resolve the UDF compatibility issue, we consider support the
> implicit cast conversion between timestamp and timestamp_ltz after some
> offline discuss with [~jark] and [~ykt836],
> This way is clean and lightweight way to resolve the UDF compatibility issue
> and doesn't change any public interface as well. BTW the implicit cast
> conversion is supported in Oracle[1]
>
> [1]https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
