Skip to content

[pull] main from MaterializeInc:main - #1222

Merged
pull[bot] merged 6 commits into
transparencies:mainfrom
MaterializeInc:main
Jul 24, 2026
Merged

pull[bot] merged 6 commits into
transparencies:mainfrom
MaterializeInc:main

Conversation

@pull

@pull pull Bot commented Jul 24, 2026 •

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

def- and others added 6 commits July 24, 2026 06:45
EXTRACT(YEAR ...) on dates and timestamps returned chrono's astronomical
year numbering, where 1 BC is year 0, so BC years were off by one: 1 BC
must be year -1 and there is no year 0.

make_timestamp passed its year argument straight to chrono, accepting
year 0 and shifting BC years by one. It also returned NULL for invalid
field values instead of erroring, and rejected 24:00:00 and 60 seconds
instead of rolling them over into the next day or minute.

Closes: SQL-467

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Verify that reissuing a graceful cluster reconfiguration for the same
target with a zero timeout cuts over to the existing target replica
instead of creating a replacement.
Interval range qualifiers like HOUR TO MINUTE now only resolve ambiguous
parts and discard fields below the range's low end, matching PostgreSQL.
Previously fields above the range's high end were dropped, and a leading
day component caused "a:b" values to be read as hours:minutes even under
MINUTE TO SECOND:

SELECT interval '1 2:03' hour to minute; -- was 02:03:00, now 1 day
02:03:00
SELECT interval '1 2:03' minute to second; -- was 00:03:00, now 1 day
00:02:03

Closes: SQL-474

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
#37838)

Interpret separated all-numeric date literals the way PostgreSQL does
under the pinned DateStyle 'ISO, MDY': a one- or two-digit leading field
starts a month-day-year date, and a two-digit year is windowed into
1970..=2069. A leading field of three or more digits keeps the
year-month-day interpretation. This applies to date, timestamp and
timestamptz parsing at the SQL layer.

      SELECT date '01/02/03';  -- now 2003-01-02, was 0001-02-03
SELECT date '99-01-08'; -- now an error (month 99), was 0099-01-08

Storage source casts stay on new frozen legacy parse functions
(parse_date_legacy and friends) so their evaluation is unchanged, per
the stability contract in mz_storage_types::sources::casts.

Closes: SQL-461

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
…utput (#37836)

The text output of arrays, lists, and maps only quoted elements exactly
equal to "NULL", but the parser treats any case variant of unquoted
"NULL" as null. A string element like 'null' was printed unquoted and
did not round-trip: ARRAY['null'] printed as {null}, which parses back
as {NULL}. Quote any element matching "NULL" case-insensitively,
matching PostgreSQL.

Closes: SQL-466

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Materialize claims IntervalStyle=postgres but spelled the months field
"month(s)" where PostgreSQL emits "mon(s)". psycopg's postgres-style
interval parser stops at the unexpected spelling and silently drops all
components after the months field, so '1 month 10 days'::interval came
back as 30 days in the default text result mode of the most-used Python
driver.

The interval parser already accepts both spellings, so round-tripping
and stored interval literals are unaffected.

Closes: SQL-463

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
@pull pull Bot locked and limited conversation to collaborators Jul 24, 2026
@pull pull Bot added the ⤵️ pull label Jul 24, 2026
@pull
pull Bot merged commit 3c0a474 into transparencies:main Jul 24, 2026
0 of 2 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants