Re: JSON_TABLE: table => column ON ERROR propagation

On Thu, Sep 17, 2026 at 5:09 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> 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.

Pushed.

------
Regards,
Alexander Korotkov
Supabase