Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wF0sz-004fCz-1K for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Apr 2026 02:30:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wF0sy-005LzP-0K for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Apr 2026 02:30:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wF0sx-005Lyw-2G; Tue, 21 Apr 2026 02:30:47 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wF0sn-00000002E7H-0Sit; Tue, 21 Apr 2026 02:30:42 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 63L2UWAT485642; Mon, 20 Apr 2026 22:30:32 -0400 From: Tom Lane To: Richard Guo cc: Amit Langote , Vik Fearing , lukas.eder@gmail.com, pgsql-bugs@lists.postgresql.org, rmt@lists.postgresql.org, =?UTF-8?Q?=C3=81lvaro_Herrera?= Subject: Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 In-reply-to: References: <19418-591ba1f29862ef5b@postgresql.org> <2abdb464-27f5-4759-bb0b-f09ab5b5ceab@postgresfriends.org> <501040.1772433449@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Tue, 21 Apr 2026 10:12:55 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <485640.1776738632.1@sss.pgh.pa.us> Date: Mon, 20 Apr 2026 22:30:32 -0400 Message-ID: <485641.1776738632@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo 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