Re: JSON_TABLE: table => column ON ERROR propagation

On Wed, Aug 12, 2026 at 2:44 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Fri, Aug 7, 2026 at 8:00 AM Nikita Malakhov <hukutoc(at)gmail(dot)com> wrote:
> > Alexander, IMHO the 2nd option is the best. To revise queries for 2 versions
> > could involve a lot of work, testing and system behavior changes.
>
> Thank you for your feedback. Any other opinions?

Hearing nothing back I suppose we should go with option 2: master
only, release note for v20.

Reasons, with the precedents I checked:

* Nothing is silently wrong in 17-19: the table-level clause is
ignored for columns consistently, and the result is the NULL an
explicit NULL ON ERROR would give. Compare 4c75cc78630, which we did
back-patch into 17 long after GA: there RETURNING numeric(4,1) DEFAULT
99999.999 returned a value the type itself rejects, and it could be
stored into a numeric(4,1) column. We back-patch when the old
behavior yields results no correct query could want, not when it is
just non-conforming.

* We documented the current behavior in 17 -- "this clause does not
affect the errors that occur when evaluating columns". We are
retracting a promise, not fixing an undocumented accident.

* 9321d2fdf80 is the closest structural precedent that went to a next
major release only. It changed foreign key collation handling after
the standard's own rule turned out to be wrong. The new rule rejects
schemas that used to be valid, and that is exactly why it was put to
v18: users meet it at a major upgrade, where reading the notes and
adjusting is part of the job. Ours is milder, and fits the same
placement.

* Our change is quite small: only queries with a table-level ERROR ON
ERROR that rely on columns still returning NULL. Without it, or with
explicit per-column clauses, nothing changes.

v2 attached; code unchanged from v1, the commit message records the
above. Suggested release note: a JSON_TABLE column without its own ON
ERROR clause now inherits ERROR ON ERROR from the table-level clause;
add an explicit NULL ON ERROR to keep the old behavior.

I'm going to push this to master if no objections.

------
Regards,
Alexander Korotkov
Supabase