PostgreSQL 19 JSON_ARRAY indexes can go stale after type changes
Expression indexes that 18 rejected are accepted in 19, then silently disagree with sequential scans after ALTER TYPE, cast changes, or output GUCs.
PostgreSQL 19 accepts expression indexes on JSON_ARRAY() and JSON_OBJECT() that version 18 refused, and several of those indexes can return wrong results after later schema or output-setting changes. Index scans miss rows that sequential scans still find until a REINDEX; unique and partial indexes, generated columns, and partition keys break the same way.
The earlier change that opened these indexes recurses into composites, ranges, and arrays when deciding immutability. The JSON text of some types can still change while the stored values do not: ALTER TYPE add, rename, or drop attribute on a composite; CREATE or DROP CAST on a user-defined range or base type; renaming an enum value used in a range; and, for arrays of float, bytea, and geometric types on the 19 stable line, GUCs such as extra_float_digits or bytea_output. Built-in integer ranges are correctly left alone because JSON casts are consulted only for user-defined types.
Manu reported the regression on pgsql-hackers with a short composite repro and a combined fix from Jian plus a small array adjustment. Nikolay Samokhvalov then showed that arrays of float4, float8, bytea, and geometric types (and domains over them) still go stale on 19 after the main fix, because their output functions remain immutable on that branch; a follow-on patch marks those array cases mutable while leaving scalar behavior as in 18 so existing dumps still restore. Master already treats the underlying output functions as stable, so the extra array rule is 19-only. Making every array mutable would close the hole more bluntly but would also reject many safe cases such as int4[] and text[].
A side exchange followed when an unreviewed AI-prepared patch appeared. Andres Freund argued that dumping unverified model output on the lists mostly raises noise and shifts review work onto others, and that automated list interaction should face bans after warnings. Andrey Borodin replied that transparency about AI use is preferable and that the community cannot simply wish the tools away.