Re: JSON_TABLE: table => column ON ERROR propagation - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: JSON_TABLE: table => column ON ERROR propagation
Date
Msg-id CAN-LCVN3dQJ_FQdgEJFpKDdFS8N=A=NBmZCQn8NwYmkPF6tjyQ@mail.gmail.com
Whole thread
List pgsql-hackers
Hi!

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.

On Thu, Aug 6, 2026 at 7:01 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
Hi!

While working on the JSON_TABLE PLAN clause [1], I found that our
implementation of JSON_TABLE has a standard divergence.  In our
implementation, the table-level ON ERROR clause and the column-level
ON ERROR clause are completely independent.  But according to ISO/IEC
9075-2 2023, the table-level ON ERROR clause is propagated to the
column level if the column doesn't have its own explicit ON ERROR
clause.

I can't share my copy of the standard, but I verified that Chapter
7.11 Syntax Rules 1) e) iv) and 1) f) xi) specify that if a column
element lacks an ON ERROR clause and the table-level clause is ERROR
ON ERROR, then ERROR ON ERROR applies to the column.  Otherwise (no
table-level clause or table-level clause is NULL ON ERROR), NULL ON
ERROR applies to the column.

For instance, this query returns NULL on the current master, but must
error out according to the standard.

SELECT * FROM JSON_TABLE(jsonb '"err"', '$' COLUMNS (a int PATH '$')
ERROR ON ERROR) jt;

I've drafted a patch that implements the behavior specified in the
standard.  That's not a very complicated patch, but I see a problem:
JSON_TABLE was released in PostgreSQL 17, and this patch changes
user-visible behavior.

I see some options we can go ahead with:
1) Backpatch this to PostgreSQL 17, and issue release notes that users
should check and revise their queries.
2) Patch only master, and issue the same notes for the PostgreSQL 20 release.
3) Add the GUC controlling this behavior (I don't really like that).

Any thoughts?

Links.
1. https://www.postgresql.org/message-id/CAPpHfdt%3DLncQH9PAq9O8qO7KZcTT9rOsxLLanscRF7xDFvK8mA%40mail.gmail.com

------
Regards,
Alexander Korotkov
Supabase


--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company

pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
Next
From: Peter Smith
Date:
Subject: Re: pg_createsubscriber: allow duplicate subscription names