[FLINK-15602][table-planner-blink] Padding TIMESTAMP type to respect …

[docete]

…the precision when casting timestamp to varchar

What is the purpose of the change

According to SQL 2011 Part 2 Section 6.13 General Rules 11) d)

If SD is a datetime data type or an interval data type then let Y be the shortest character string that
conforms to the definition of in Subclause 5.3, “”, and such that the interpreted value of Y is SV and the interpreted precision of Y is the precision of SD.

This PR padding the TIMESTAMP type to respect the precision when casting timestamp to varchar.

Brief change log

• c53d150 Padding TIMESTAMP type to respect precision

Verifying this change

This change is already covered by existing tests, such as TempralTypeTests.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
• The serializers: (yes / no / don't know)
• The runtime per-record code paths (performance sensitive): (yes / no / don't know)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
• The S3 file system connector: (yes / no / don't know)

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[flinkbot]

Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community
to review your pull request. We will use this comment to track the progress of the review.

Automated Checks

Last check on commit c53d150 (Fri Jan 17 06:19:25 UTC 2020)

Warnings:

• No documentation files were touched! Remember to keep the Flink docs up to date!

_{Mention the bot in a comment to re-run the automated checks.}

Review Progress

• ❓ 1. The [description] looks good.
• ❓ 2. There is [consensus] that the contribution should go into to Flink.
• ❓ 3. Needs [attention] from.
• ❓ 4. The change fits into the overall [architecture].
• ❓ 5. Overall code [quality] is good.

Please see the Pull Request Review Guide for a full explanation of the review process.

The Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot approve description to approve one or more aspects (aspects: description, consensus, architecture and quality)
• @flinkbot approve all to approve all aspects
• @flinkbot approve-until architecture to approve everything until architecture
• @flinkbot attention @username1 [@username2 ..] to require somebody's attention
• @flinkbot disapprove architecture to remove an approval you gave earlier

[flinkbot]

CI report:

• c53d150 Travis: FAILURE Azure: FAILURE
• ce96d1f Travis: FAILURE Azure: SUCCESS
• 8f78bcd Travis: SUCCESS Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run travis re-run the last Travis build
• @flinkbot run azure re-run the last Azure build

[wuchong]

I find that we have a lot of this changes that remove the toTimestamp from the tests.

I'm wondering could we align the toTimestamp with the SQL timestmap literal?

Currently "2018-07-26 17:18:19".toTimestamp actually calls "2018-07-26 17:18:19".cast(DataTypes.TIMESTAMP(3)), however, according to the javadoc of toTimestamp, it should be the same with SQL TIMESTAMP string.

[docete]

Currently toTimestamp in Table API can't align to Timestamp literal, because it use SqlTimeTypeInfo.TIMESTAMP as the target type.

[docete]

There is no such thing in table API which align to Timestamp literal in SQL. I will add some comments to clarify this.

[wuchong]

Currently, we don't have a way to construct TIMESTAMP WITH LOCAL TIME ZONE literal. timestampTz will lose the original timestamp literal precision and use a default 6 precision. The tests are counter-intuitive because we are padding zeros for a timestamp literal.

Could we improve the timestampTz a little bit? It can extract precision from the literal string, and cast to the local timestamp with the extracted precison.

[docete]

timestampTz(expr) is a shortcut of CAST(expr AS TIMESTAMP WITH LOCAL TIME ZONE), Do you mean we should provide a builtin UDF to convert TIMESTAMP literal to TIMESTAMP WITH LOCAL TIME ZONE?

[wuchong]

I mean we should improve timestampTz to convert timestamp without precision loss.

private def timestampTz(str: String) = {
  val precision = extractPrecision(str)
   s"CAST(TIMESTAMP '$str' AS TIMESTAMP($precision) WITH LOCAL TIME ZONE)"
}

[docete]

OK, According to SQL standard, for timestamp literal, the length of the second fraction should be the precision.

[wuchong]

LGTM. I also verified the e2e test in my local machine, need some modification on the e2e tests.

Will merge this.