Skip to content

v2.3.3-ce — Date math you can trust, and sturdier external Parquet

Released 2026-10-26 · GitHub release

v2.3.3 is a correctness release on top of v2.3.2-ce. It closes ten findings from a real field report — led by a date-arithmetic bug that could skew any time-windowed analytics — hardens reads over third-party Parquet, and folds in two engine-stability fixes surfaced while validating the release build itself. No new surface to learn: this makes the SQL you already write right.

Why it matters

If you filter or cohort on INTERVAL '… ' YEAR/MONTH or convert text to DATE, your results are now correct to the calendar. External Parquet datasets that evolve their schema keep reading. And the engine is sturdier under deep, complex queries.

New in v2.3.3

1. Calendar date arithmetic is correct

Outcome: time-windowed analytics return the right rows.

Previously every INTERVAL was reduced to an approximate integer number of days, and a calendar unit written as a field suffix was ignored entirely — so CURRENT_DATE - INTERVAL '10' YEAR behaved like minus ten days, and sub-day intervals were dropped to zero. Any query that filtered or bucketed on year/month windows could silently return the wrong rows.

Now:

SELECT DATE '2026-10-24' - INTERVAL '10' YEAR;      -- 2016-10-24
SELECT DATE '2026-10-24' - INTERVAL '10 years';     -- 2016-10-24 (inline form)
SELECT DATE '2024-03-31' - INTERVAL '1' MONTH;      -- 2024-02-29 (leap-aware, month-end clamp)
SELECT DATE '2026-10-24' + INTERVAL '1.5 hours';    -- 2026-10-24 01:30:00 (sub-day kept)
  • YEAR / MONTH do true calendar arithmetic — leap years counted, the result clamped to the last valid day of the destination month.
  • Fixed-duration units (WEEK/DAY/HOUR/MINUTE/SECOND, and millisecond / microsecond / nanosecond in interval text) keep exact, nanosecond precision.
  • CAST(value AS DATE) has strict validation across SELECT, filters and INSERT … VALUES; NULL propagates, and invalid dates / times / trailing junk error instead of passing silently.
  • Unknown or contradictory units, YEAR TO MONTH ranges and compound strings now return a clear error — they are never approximated as days.

See calendar intervals and DATE conversion for the full grammar and clamping rules.

2. Scalar functions and boolean logic

Outcome: NULL-safe math and short-circuit evaluation.

  • SQRT(NULL), POWER(NULL, 2), POWER(2, NULL) now return NULL (they used to error), and both accept exact DECIMAL inputs (returning DOUBLE).
  • FALSE AND … / TRUE OR … short-circuit the right-hand side, while the three-valued (UNKNOWN) truth tables stay correct.

3. Sturdier reads over third-party Parquet

Outcome: external datasets that evolve keep working.

  • Nullability-only schema differences reconcile — REQUIRED/OPTIONAL mismatches between files widen to nullable instead of failing the read.
  • Additive columns union by name — files written before a new column was added expose typed NULLs for it; REFRESH surfaces newly added logical columns on an inferred registration.
  • An authorized empty location can register with a declared schema and return zero rows, then light up as the first files arrive.
  • Error diagnostics now name the offending file and column, with both the type and nullability descriptions.

See Reading third-party Parquet datasets for the schema and refresh model.

4. ORDER BY on a computed alias, across batches

Outcome: sorting on a derived column no longer breaks on sparse data.

Empty and all-NULL computed results now retain their expression/column types, so an ORDER BY computed_alias is stable even when a scan yields no matching rows; batch concatenation stays strict and points at a genuine mismatch.

5. Engine stability under deep, complex queries

Outcome: the engine stays up on query shapes that pushed its limits.

Validating the shipping release build (not a debug build) surfaced two crashes the debug build masked, both fixed here:

  • A common-table expression whose body produced zero rows recorded no schema (CTE '…' schema not found); it now registers a fallback schema from the CTE's own columns.
  • A view body is now executed on a fresh scoped task, and the serving-worker stack was raised, so a cross-database RENAME with a dependent view — and deeply nested join/aggregate/CTE plans — no longer risk a worker-stack overflow.

Proof

Validated on the release artifact: the state-asserting feature validator passes 312 / 0; the full recipe certification sweep is 177 / 187 with zero regressions against v2.3.2-ce (the ten not-certified recipes fail identically on v2.3.2 and need external infrastructure — S3/MySQL sources, media blobs, AutoML setup); the non-AVX-512 runtime canary boots and runs a model with no SIGILL; and a matched-build A/B shows no query-speed regression.

Boundaries worth knowing

  • Exact DECIMAL values are still returned as JSON strings to preserve full precision; an explicit CAST(… AS DOUBLE) yields a numeric JSON value. This is deliberate — changing the default would risk silently rounding financial values.
  • Dates, timestamps and intervals keep the engine's ISO-text representation; this release does not add a persisted DATE or INTERVAL column type.
  • With the pinned SQL parser, an inline interval on the left of arithmetic needs parentheses — (INTERVAL '2 weeks') + DATE '2024-02-20' — or use the suffix form INTERVAL '2' WEEK.
  • Foreign-Parquet NULL synthesis and schema union apply to external tables only; managed datasets keep their verified-manifest read path. Older inferred external registrations may need re-registration to relax nullability.

Upgrade

curl -fsSL https://get.synapcores.com | sh            # installs the latest (v2.3.3-ce)
# or pin:
docker pull synapcores/community:v2.3.3-ce

Community Edition. Seamless upgrade from v2.3.x — no on-disk format change.