[CALCITE-1690] Calcite timestamp literals cannot express precision above millisecond, TIMESTAMP(3)

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: avatica-1.10.0, 1.13.0
• Assignee: Julian Hyde
• Reporter: Remus Rusanu
• Created: 10/Mar/17 12:56
• Updated: 27/Feb/24 22:23
• Resolved: 31/May/17 18:10

Description

RexBuilder.makeTimestampLiteral accepts the TS as a Java Calendar instance. Calendar type has only ms precision, thus types like TIMESTAMP(9) cannot be represented.
This results in incorrect results in Hive due to constant reduction:

hive> explain select c17 from testjdbcdriverdatatypetbl where c17='2012-04-22 09:00:00.123456789';
OK
Plan optimized by CBO.

Stage-0
  Fetch Operator
    limit:-1
    Select Operator [SEL_2]
      Output:["_col0"]
      Filter Operator [FIL_4]
        predicate:(c17 = 2012-04-22 09:00:00.123)
        TableScan [TS_0]
          Output:["c17"]

hive> select c17 from testjdbcdriverdatatypetbl where c17='2012-04-22 09:00:00.123456789';
OK
Time taken: 0.687 seconds

hive> set hive.cbo.enable=false;
hive> explain select c17 from testjdbcdriverdatatypetbl where c17='2012-04-22 09:00:00.123456789';
OK
Stage-0
  Fetch Operator
    limit:-1
    Select Operator [SEL_2]
      Output:["_col0"]
      Filter Operator [FIL_4]
        predicate:(c17 = '2012-04-22 09:00:00.123456789')
        TableScan [TS_0]
          Output:["c17"]

hive> select c17 from testjdbcdriverdatatypetbl where c17='2012-04-22 09:00:00.123456789';
OK
2012-04-22 09:00:00.123

Note how with CBO enabled the qualified row is missed. The plan shows that the constant was truncated to ms.

Issue Links

• depends upon: CALCITE-1612 Release Avatica 1.10
• relates to: CALCITE-4959 SQL validator should throw when a type's precision is greater than maxPrecision
• relates to: CALCITE-5538 TimestampString should allow fractional seconds ending in zero
• links to: GitHub Pull Request #9