Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor>

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, lukas(dot)eder(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, rmt(at)lists(dot)postgresql(dot)org, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor>
Date: 2026-04-21 02:30:32
Message-ID: 485641.1776738632@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> Another question I'd like to raise: is it OK to commit this patch to
> master given that feature freeze has passed? I think the answer is
> yes, because this is arguably a bug fix rather than a new feature.
> However, it does change user-visible behavior, and existing app code
> that relies on the NULL behavior would break. So if we commit it, we
> need to add in the release notes about this incompatibility.

Well, if we definitely intend to commit a compatibility-breaking
change, I think it's better to commit it sooner not later. If we
wait till v20, all we accomplish is to give users another year to
write code that depends on the old behavior.

However, usually at this stage of the cycle the answer to such
questions is "let the RMT decide". Take the question to them
(cc'd).

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2026-04-21 03:20:02 Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor>
Previous Message Richard Guo 2026-04-21 01:12:55 Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor>