fix: numeric/bigint aggregates, enum order, quoted plpgsql idents, json dates (4.0.4)

[RiyaSharma03]

More testing of rapidnative-website's migration validator over the same 120 production projects, PGlite vs pg-mem, now with (a) ~4,500 mutation probes generated from each project's own schema (must-reject: policy on a missing column, uuid = text / int = text / bool = text, non-boolean policy, retyping a policy column, trigger on a missing function, wrong-type insert, dangling FK, duplicate column, duplicate seed rows, NULL into NOT NULL; must-accept: add column, index, casted policy, comment, updated_at trigger, CHECK) and (b) reads over the seeded data: every row of every table, sum/max/min/count/avg over every numeric column, ordered reads, row_to_json, catalogue reads.

Wrong results (all already in 3.5.0)

• sum() over numeric / bigint concatenated the digit strings: sum of 10 and 32.5 was '1032.5', bigint 5 + 7 was '57'; avg was computed from that (or NaN). Now exact (Decimal / BigInt), so sum(0.1, 0.2) is 0.3 and large bigints keep their digits.
• max / min compared numeric / bigint as text (max of 9 and 10 was '9'). Now by type.
• Enums ordered alphabetically, not by declaration: order by priority, priority > 'medium', and max/min (which now accept enums).

Rejected valid SQL

• plpgsql: a double-quoted identifier was split into three tokens, so new."updated_at" := now() in a trigger failed to compile (299 of the probes). Quoted names now work in triggers, functions and DO blocks.

JSON output

• Dates and times in Postgres' text format ("2026-05-26", "2026-05-26T10:30:00", "2026-05-26T10:30:00.5+00:00") instead of JS toISOString(), in row_to_json, json_agg, to_json[b], json[b]_build_object, json[b]_build_array. tinbase builds REST answers with row_to_json, so this matters for the editor too. Numerics inside the json builders are numbers, as in Postgres.

Postgres wording for errors the validator shows the model

• column "x" of relation "t" already exists (42701), null value in column "x" of relation "t" violates not-null constraint (23502), argument of POLICY must be type boolean…, and syntax error at or near "x" / syntax error at end of input (42601) as the first line of a parse error.

Results

• Mutation probes: 0 verdict differences (was 299); seeded reads: 0 differences beyond float4 rounding and LIMIT without ORDER BY, once numbers compare by value.
• Real migrations/seeds: still 0 differences on all 120.
• bun test: 1352 pass, 0 fail. rapidnative-website: all 34 CI suites as on main (test:agent needs Supabase env locally).

Known, not changed here

• numeric scale: Postgres prints 18.50 for numeric(10,2) / a 4.50 literal, pg-mem 18.5. Decimal already tracks the scale; printing it changes the stored digit strings, which pg-mem hashes for GROUP BY / DISTINCT / unique indexes, so it needs a canonical key first. Display-only for the validator; visible in the editor later.
• ALTER TYPE … ADD VALUE … BEFORE/AFTER does not parse (none of the 120 projects uses ADD VALUE).
• smallint is reported as integer in a few messages.

Version 4.0.4.

🤖 Generated with Claude Code