Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor>
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Vik Fearing <vik@postgresfriends.org>, lukas.eder@gmail.com, pgsql-bugs@lists.postgresql.org, Álvaro Herrera <alvherre@kurilemu.de>
Date: 2026-03-03T01:03:49Z
Lists: pgsql-bugs
On Mon, Mar 2, 2026 at 3:37 PM 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
Commits
-
Enforce RETURNING typmod for empty-set JSON_ARRAY(query)
- 9d124a14b3d4 19 (unreleased) landed
-
Fix JSON_ARRAY(query) empty set handling and view deparsing
- 8d829f5a0203 19 (unreleased) landed