GeezerVison

Review: SQL-standard interval truncation (#7690)

• bug (high), gate "tests for changed behaviour": the PR's own Rust unit test fails, so CI will be red. The underlying LongInterval::years() overflow is reachable from SQL.
• missing (medium): the PR has no test for overflow or error paths in the new constant folding (RexOptimize.intervalProductOrQuotient returns null and defers to the runtime), e.g. INTERVAL '100000000' YEAR * 100 or INTERVAL '1' DAY / 0. The literal and column results should be checked against each other there too.
• missing (medium): the PR has no test for the new (a - b) <qualifier> semantics with a multi-field qualifier (YEAR TO MONTH, DAY TO HOUR) or with TIMESTAMP WITH TIME ZONE operands. floorToLastField applies to both.
• Breaking change: it is documented in the changelog and the SQL docs, so that gate passes.

QA test I used (add to TimeArithmeticTests):

@Test
public void qaIntervalEdgeCases() {
    var ccs = this.getCCS("""
            CREATE TABLE Q(m INT);
            CREATE VIEW V AS SELECT
                CAST(CAST(CAST(CAST(m AS INTERVAL MONTH) AS INTERVAL YEAR) AS INTERVAL MONTH) AS INT) AS ym
            FROM Q;""");
    ccs.stepWeightOne("INSERT INTO Q VALUES (-2147483648);", """
             ym
            ----
             -2147483640""");
}

Verdict: PR bug (incomplete test update), high confidence.

ca120407f changed MONTH-interval subtraction and correctly updated the expected
values in aggregate_tests2/test_atbl_interval.py ("Validated on HSQLDB"), but
missed four sibling files in aggregate_tests6 that read the same
atbl_interval_months view and hardcode its old values: test_interval_mths_min.py,
test_interval_mths_max.py, test_interval_mths_argmin.py, test_interval_mths_argmax.py
(plain, DISTINCT, GROUP BY and FILTER variants).

• Failing job: Runtime Integration Tests (arm64), log lines 726-765
• interval_argmin_distinct_mths_gby_res mismatch: expected f_c3: -33, f_c5: +56 (id 0), f_c2: +557, f_c3: +87, f_c5: +340 (id 1) — received -34, +57, +558, +88, +341
• Those "received" values match exactly what the view's ARG_MIN/MIN/MAX/ARG_MAX would recompute from the already-corrected c1_minus_c3/c3_minus_c1/c2_minus_c3/c3_minus_c2 values two rows have in the updated test_atbl_interval.py
• The test run stops at the first failing assertion (alphabetically interval_argmin_distinct_mths_gby_res is first), which is why only one view showed up as failed — the sibling views above are equally stale and would fail next

Fix on fred/observe-7692-41190119080: recomputed all affected expected values from
the table data and the new, already-validated atbl_interval_months_res numbers.
EVERY/SOME/COUNT(DISTINCT) views over the same table are unaffected (verified the
underlying comparisons/distinct-counts don't change sign or cardinality).

Take the fix:

git fetch origin fred/observe-7692-41190119080 && git cherry-pick dbf6d4c3b

Compare: issue7690...fred/observe-7692-41190119080