docete commented on a change in pull request #10105:
[Flink-14599][table-planner-blink] Support precision of TimestampType in blink
planner
URL: https://github.com/apache/flink/pull/10105#discussion_r345604974
##########
File path:
flink-table/flink-table-planner-blink/src/test/scala/org/apache/flink/table/planner/expressions/DateTimeTypesTest.scala
##########
@@ -177,14 +193,14 @@ class TemporalTypesTest extends ExpressionTestBase {
testAllApis(
'f0.cast(DataTypes.TIMESTAMP(3)),
"f0.cast(SQL_TIMESTAMP)",
- "CAST(f0 AS TIMESTAMP)",
- "1990-10-14 00:00:00.000")
+ "CAST(f0 AS TIMESTAMP(3))",
+ "1990-10-14 00:00:00")
Review comment:
SQL 2011 defined the interpreted string value as `the shortest character
string that conforms to the definition of literal`. And I checked other DBMSs:
MySQL 5.6: 'SELECT CAST(TIMESTAMP '1970-01-01 11:22:33' AS DATETIME(3))' =>
'1970-01-01T11:22:33Z'
PG 9.6: `SELECT CAST('1970-01-01 11:22:33' AS TIMESTAMP(3))' =>
'1970-01-01T11:22:33Z'
ORACLE 11g R2: `select CAST(TIMESTAMP '1970-01-01 11:22:33' AS TIMESTAMP(3))
from log_table` => '1970-01-01 11:22:33.0'
MSSQL 2017: `SELECT CAST({ts '1970-01-01 11:22:33.000'} AS DATETIME),
CAST({ts '1970-01-01 11:22:33.000'} AS DATETIME2)` => '1970-01-01T11:22:33Z',
'1970-01-01 11:22:33.0000000'
Only MSSQL's DATETIME2 will preserve tailing '0's and the precision can not
be specified. IMO we shouldn't preserve the tailing '0's.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
