Timo Theusner created FLINK-40222:
-------------------------------------
Summary: ValueLiteralExpression.asSerializableString() drops
leading-field precision for INTERVAL literals
Key: FLINK-40222
URL: https://issues.apache.org/jira/browse/FLINK-40222
Project: Flink
Issue Type: Bug
Components: Table SQL / API
Reporter: Timo Theusner
{{ValueLiteralExpression}} serializes {{INTERVAL_YEAR_MONTH}} and
{{INTERVAL_DAY_TIME}} literals using hardcoded format strings ({{{}INTERVAL
'%d-%d' YEAR TO MONTH{}}} and {{{}INTERVAL '%d %02d:%02d:%02d.%d' DAY TO
SECOND(3){}}}), instead of reading the actual resolution and precision from the
literal's {{YearMonthIntervalType}} / {{{}DayTimeIntervalType{}}}.
As a result:
* Any interval whose leading field needs more than the default 2 digits (years
≥ 100, days ≥ 100) is serialized without its precision qualifier. Downstream
SQL parser then assumes YEAR(2)/DAY(2) and rejects the value with Interval
field value <n> exceeds precision of YEAR(2)/DAY(2) field.
* The qualifier is always emitted as YEAR TO MONTH / DAY TO SECOND(3)
regardless of the literal's actual resolution (e.g. YEAR-only, MONTH-only, HOUR
TO MINUTE, SECOND, etc.), so non-default resolutions serialize incorrectly.
* Fractional seconds are truncated to milliseconds (getNano() / 1_000_000) and
not zero-padded, so e.g. a 5ms fraction serializes as .5 instead of .005, and
sub-millisecond precision is silently lost even when the type allows up to 9
digits.
Repro:
{code:java}
public static class MyPtf extends ProcessTableFunction<String> {
public void eval(final Period period) {
collect(period.toString());
}
}
tableEnv.fromCall(MyPtf.class, Period.of(9999, 11, 0)).execute().print();
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
