alexandrefimov opened a new pull request, #5237: URL: https://github.com/apache/calcite/pull/5237
## Jira Link [CALCITE-4543](https://issues.apache.org/jira/browse/CALCITE-4543) ## Changes Proposed `INTERVAL '1.123456789' SECOND(1,9)` validates, the row type comes back as `INTERVAL SECOND(1, 9)`, and the plan is `LogicalValues(tuples=[[{ 1123 }]])` — the same value as `INTERVAL '1.123' SECOND(1,3)`. The digits the qualifier declares are accepted and then dropped. Where they go: `SqlIntervalQualifier.normalizeSecondFraction` scales the fraction to milliseconds, `fillDayTimeIntervalValueArray` stores `secondFrac.intValue()`, and `SqlLiteral.getValueAs(BigDecimal.class)` builds its result from `getValueAs(Long.class)`, a whole number of milliseconds. `SqlNodeToRexConverterImpl` asks for that `BigDecimal`, and `RexBuilder.makeIntervalLiteral` would have carried a fraction had it been given one. The change keeps every existing unit and contract: - `fillDayTimeIntervalValueArray` fills a seventh element with the nanoseconds below the millisecond. Elements 0..5 keep their meaning, so its twelve call sites and `intervalToMillis` are unaffected. - `SqlParserUtil.intervalToExactMillis` reports milliseconds with that fraction. `intervalToMillis` still rounds towards zero and its result is unchanged. - `SqlLiteral.getValueAs(BigDecimal.class)` uses the exact value for day-time intervals. The scale stays 0 unless the literal really has digits below the millisecond, so plans for ordinary intervals are untouched: ``` INTERVAL '1.123456789' SECOND(1,9) -> { 1123.456789 } was { 1123 } INTERVAL -'1.123456789' SECOND(1,9) -> { -1123.456789 } INTERVAL '1 02:03:04.123456789' DAY(2) TO SECOND(9) -> { 93784123.456789 } INTERVAL '1.123' SECOND(1,3) -> { 1123 } unchanged INTERVAL '2' SECOND -> { 2000 } unchanged ``` One API-visible consequence worth weighing: `evaluateIntervalLiteral` is public, and for a day-time qualifier it now returns seven elements rather than six. Inside this repository only `SqlParserUtil` reads the values — `SqlValidatorImpl` calls it for the validation it performs and then discards the array — but code outside that assumes a length of six would notice. Two things I left alone, and would fold in if you would rather they moved together: `RexLiteral.fromJdbcString` still goes through `intervalToMillis`, and `getValueAs(Long.class)` still rounds towards zero rather than to nearest. `./gradlew build` passes locally apart from `OsAdapterTest.testPs` and `testPsDistinct`, which parse `ps` output and fail on a clean `main` in this locale as well, where it prints `0,4` for `0.4`. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
