/{server, testing}: enable successful reparsing

[coffeegoddd]

Fixes #3529. Interval literals now serialize as quoted SQL, so timestamp defaults using interval arithmetic can be reparsed during index creation and inserts.

[github-actions]

	Main	PR
Total	42090	42090
Successful	20955	20956
Failures	21135	21134
Partial Successes1	5405	5405

	Main	PR
Successful	49.7862%	49.7885%
Failures	50.2138%	50.2115%

${\color{lightgreen}Progressions (1)}$

subselect

QUERY: select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[itoqa]

Commit: 4cb7de4: 11 test cases ran, 10 passed ✅, 1 additional finding ⚠️.

Summary

Coverage spans interval arithmetic, timestamp defaults, schema changes, time-zone handling, calendar and leap-day boundaries, and time-based aggregate windows. It includes normal persistence flows, boundary and fractional-time edge cases, invalid-input recovery, and checks that stored values and calculated results remain consistent.

Safe to merge — the only observed defect is an unrelated, pre-existing precision issue in time-window aggregates near microsecond boundaries and is not attributable to this PR. The tested behavior of the change showed no regressions or merge-blocking failures.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Arithmetic	Date, timestamp, and timestamptz calculations returned the expected calendar date, time, and microseconds for the complete interval.
✅	—	General	Zero, negative, mixed-calendar, and fractional intervals produced the expected arithmetic results and persisted defaults.
✅	—	General	The direct calculation and the saved timestamp matched exactly in UTC and America/New_York, including the calendar and fractional parts of the interval.
✅	—	General	The mixed window statement returned a clear unsupported-offset error and no partial rows. A valid window query run afterward returned the same frame sums as before the error.
✅	—	General	Timestamp arithmetic and time-based window totals both returned the expected results. Rows inside the three-minute range were included in the correct frame.
✅	—	General	The interval default stayed present and quoted after two index changes. A new row also kept the original mixed calendar and fractional interval value.
✅	—	General	Date, timestamp, and timezone-aware timestamp calculations stayed correct at month-end and leap-day boundaries while keeping fractional seconds.
✅	—	Interval	The default timestamp stayed valid after two index changes, and inserting a default row produced a value exactly three minutes after the statement time.
✅	—	Rev	A missing expiration value received a timestamp about three minutes ahead, while the explicit timestamp stayed exact before and after index creation.
✅	—	Window	The local test service stopped the check before the SQL query ran, so no product failure was observed. The interval window path is supported by the inspected code and a separate local interval-window check completed successfully.
⚠️		General	The row at 00:03:00.000001 included the 00:00:00 value and returned 15 instead of 14. The row at 00:02:59.999999 included the 00:06:00 value and returned 30 instead of 14, while the exact 00:03:00 boundary was included correctly.

Additional Findings Details

These findings are unrelated to the current changes but were observed during testing.

🟡 Microsecond-near window rows use the wrong frame

• Severity: Medium
• Description: The row at 00:03:00.000001 included the 00:00:00 value and returned 15 instead of 14. The row at 00:02:59.999999 included the 00:06:00 value and returned 30 instead of 14, while the exact 00:03:00 boundary was included correctly.
• Impact: Time-window queries can return wrong aggregate totals for rows just across a microsecond boundary. Reports or other decisions based on those totals may be inaccurate, but the issue is limited to this temporal query pattern.
• Steps to Reproduce:
  1. Create a timestamp column with rows at 00:00:00, 00:02:59.999999, 00:03:00, 00:03:00.000001, and 00:06:00, using values 1, 2, 4, 8, and 16.
  2. Run a RANGE window with INTERVAL '3 minutes' PRECEDING and CURRENT ROW, and another with CURRENT ROW and INTERVAL '3 minutes' FOLLOWING.
  3. Check the aggregate for 00:03:00.000001 and for 00:02:59.999999.
  4. Compare the results with temporal membership: the first row's lower bound is 00:00:00.000001, and the second row's upper bound is 00:05:59.999999.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The SQL result demonstrates a production query defect rather than a harness failure: the query completed and returned deterministic, but incorrect, frame aggregates. In server/ast/window.go:67-95, nodeWindowDef converts each offset through nodeExpr and places the resulting expression in a Vitess FrameBound. The current DInterval branch in server/ast/expr.go:567-571 returns pgexprs.NewInterval(node.Duration), and server/expression/interval.go:43-52 stores a GMS TimeDelta whose nanoseconds are converted with d.Nanos() / 1000. The resulting interval is then consumed by the temporal RANGE evaluator. That path does not preserve the expected microsecond edge membership shown by the reproduction. However, the PR diff shows that the previous window-specific DInterval branch in server/ast/window.go also directly constructed pgexprs.NewInterval(intervalOffset.Duration); the new generic route is behaviorally equivalent for this input. The smallest practical fix is to correct the interval-aware RANGE boundary evaluation or its precision-preserving time-delta conversion, then add this five-row microsecond-edge case as a regression test. This should be addressed separately from the PR's reparsing change unless additional diff evidence ties the precision behavior to another changed line.

Evidence Package

• text/BF-TIME-3/BF-TIME-3-microsecond-window-evidence.txt — 4 KB

Tip

Reply with @itoqa to send us feedback on this test run.

[coffeegoddd]

@coffeegoddd DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.48	2.43	-2.02
groupby_scan_postgres	81.48	81.48	0.0
index_join_postgres	2.26	2.26	0.0
index_join_scan_postgres	1.64	1.64	0.0
index_scan_postgres	467.3	467.3	0.0
oltp_point_select	0.38	0.38	0.0
oltp_read_only	6.55	6.55	0.0
select_random_points	0.73	0.73	0.0
select_random_ranges	1.08	1.08	0.0
table_scan_postgres	467.3	467.3	0.0
types_table_scan_postgres	1191.92	1191.92	0.0

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	4.57	4.57	0.0
oltp_insert	2.26	2.26	0.0
oltp_read_write	12.52	12.52	0.0
oltp_update_index	2.48	2.48	0.0
oltp_update_non_index	2.18	2.18	0.0
oltp_write_only	5.88	5.77	-1.87
types_delete_insert_postgres	5.0	5.0	0.0

[Hydrocharged]

Need to add tests that the default value is actually correct after insertion. SELECT (col - now()) <= interval is one way to test it

[itoqa]

Ito Diff Report — 4cb7de4 → 66fec07: 6 test cases ran, 6 passing ✅.

Diff Summary

Coverage focused on timestamp defaults and interval arithmetic, including preserving explicit values through schema changes, exact time offsets, and time-based window calculations. It also exercised boundary conditions, repeated and reordered queries, and clear rejection of unsupported or invalid window modes, covering both normal behavior and adversarial input handling.

Safe to merge — the exercised behavior is healthy, with no PR-attributable regressions, new failures, or previously flagged failures still present. No merge blocker was identified; unrelated coverage gaps are not evidence of a problem with this change.

Tests run by Ito

Result	State	Severity	Type	Description
✅	Passing	—	General	Generated timestamps kept the three-minute offset, and all supplied expiration times stayed unchanged after the index rewrite.
✅	Passing	—	General	Supported RANGE and ROWS bounds returned the expected rows and sums. GROUPS and the invalid mode were rejected with the expected errors.
✅	Passing	—	General	Supported RANGE and ROWS window frames returned the expected sums, including preceding, following, current-row, and unbounded cases. Repeating the queries and running them in reverse order produced the same results.
✅	Passing	—	Defaults	The table and both indexes were created successfully. A later insert that omitted both timestamp columns stored expires_at exactly three minutes after inserted_at.
✅	Passing	—	Interval	Rows that used timestamp defaults expired exactly three minutes after insertion, and the explicit historical timestamp stayed unchanged.
✅	Passing	—	Window	A supported RANGE query with a two-minute preceding interval returned the expected sums: 10, 30, 50, and 70.
⏸️	Skipped	—	Arithmetic	Date, timestamp, and timestamptz calculations returned the expected calendar date, time, and microseconds for the complete interval.
⏸️	Skipped	—	General	Zero, negative, mixed-calendar, and fractional intervals produced the expected arithmetic results and persisted defaults.
⏸️	Skipped	—	General	The direct calculation and the saved timestamp matched exactly in UTC and America/New_York, including the calendar and fractional parts of the interval.
⏸️	Skipped	—	General	The mixed window statement returned a clear unsupported-offset error and no partial rows. A valid window query run afterward returned the same frame sums as before the error.
⏸️	Skipped	—	General	Timestamp arithmetic and time-based window totals both returned the expected results. Rows inside the three-minute range were included in the correct frame.
⏸️	Skipped	—	General	The interval default stayed present and quoted after two index changes. A new row also kept the original mixed calendar and fractional interval value.
⏸️	Skipped	—	General	Date, timestamp, and timezone-aware timestamp calculations stayed correct at month-end and leap-day boundaries while keeping fractional seconds.
⏸️	Skipped	—	Rev	A missing expiration value received a timestamp about three minutes ahead, while the explicit timestamp stayed exact before and after index creation.

Tests that are no longer relevant

Below are tests that previously ran and are no longer relevant:

Type	Test	Description
General	Microsecond-near window rows use the wrong frame	Dropped because The current commit changes stored interval-default serialization assertions and carries no temporal frame-edge change or claim.

Tip

Reply with @itoqa to send us feedback on this test run.