On Thu, Sep 17, 2026 at 5:09 PM Alexander Korotkov <[email protected]> wrote: > On Wed, Aug 12, 2026 at 2:44 PM Alexander Korotkov <[email protected]> > wrote: > > On Fri, Aug 7, 2026 at 8:00 AM Nikita Malakhov <[email protected]> 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
