MIME-Version: 1.0
References: <19418-591ba1f29862ef5b@postgresql.org> <2abdb464-27f5-4759-bb0b-f09ab5b5ceab@postgresfriends.org>
 <CAMbWs4_4Zc7O4pCU_nJU_8=Y2bOS3sEXJR=WH39Kc__UuaCW3w@mail.gmail.com>
 <CAMbWs4_f-4BqvfKTt0YbkOky+Gf0Mpi2kCT3CAE8brZFnK275Q@mail.gmail.com>
 <CAMbWs4-y4CEy66yA-Hh+6Snqbok3XTMFj5h87gUk_15Hhjd3qw@mail.gmail.com> <501040.1772433449@sss.pgh.pa.us>
In-Reply-To: <501040.1772433449@sss.pgh.pa.us>
From: Richard Guo <guofenglinux@gmail.com>
Date: Tue, 3 Mar 2026 10:03:49 +0900
Message-ID: <CAMbWs49P2z40f5yb_97ErwtC9ocdR5QQN0gWUZtjgot9+iGAcg@mail.gmail.com>
Subject: Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC
 9075-2:2023(E) 6.34 <JSON value constructor>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Vik Fearing <vik@postgresfriends.org>, lukas.eder@gmail.com, 
	pgsql-bugs@lists.postgresql.org, =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAMbWs49P2z40f5yb_97ErwtC9ocdR5QQN0gWUZtjgot9%2BiGAcg%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 2, 2026 at 3:37=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ... doesn't that point disqualify it from being back-patched?
> People don't like unprompted behavioral changes in minor releases.
> "This is what the standard says" is not strong enough to justify
> changing behavior that was not obviously broken (like, say, crashing).

Fair point.  Changing user-facing output is not something we want to
surprise users with in a minor release.  So this will be a master-only
fix.

> Another point is that the previous coding already failed to
> be round-trippable, ie you wrote JSON_ARRAY() but what comes
> out in view decompilation is JSON_ARRAYAGG().  This makes that
> situation considerably worse.  We should endeavor to not expose
> implementation details like that.  (To be clear, I don't object
> if EXPLAIN shows that sort of thing.  But it shouldn't creep
> into view dumps.  We've regretted doing that in the past.)

That is a good point I hadn't considered.  So I think the ideal fix is
to have the parser preserve the user's original JSON_ARRAY(query)
syntax as much as possible, and then defer the JSON_ARRAYAGG rewrite
trick to the planner, perhaps during expression preprocessing.

- Richard