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

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Vik Fearing <vik(at)postgresfriends(dot)org>, lukas(dot)eder(at)gmail(dot)com, pgsql-bugs(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-03-04 06:35:56
Message-ID: CAMbWs48MrtzbG=3B9Z=J6gLRL47hfhfP9vz0yCws3Xbc0Li11g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Mar 3, 2026 at 11:32 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> On Tue, Mar 3, 2026 at 10:03 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> > 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.

> I tried hacking on this idea to see how it would look in practice, and
> here is what I got.

Here is an updated version of the patch. The main change is that it
now uses DirectFunctionCall1 to build the empty JSON array constant,
which is more efficient and consistent with other call sites.

- Richard

Attachment Content-Type Size
v3-0001-Fix-JSON_ARRAY-query-empty-set-handling-and-view-.patch application/octet-stream 21.8 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2026-03-04 08:43:13 BUG #19425: Parametric settings in collation not working in rule syntax
Previous Message PG Bug reporting form 2026-03-03 19:23:01 BUG #19424: Concurrent PQconnectdb() calls hang on Windows