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> <CAMbWs49P2z40f5yb_97ErwtC9ocdR5QQN0gWUZtjgot9+iGAcg@mail.gmail.com>
 <CAMbWs4-NuYP+0Zq9=Ufwy5GcM0XQnEqWjJFucaRGO4EQgiCcow@mail.gmail.com> <CAMbWs4-ra9mkBhUs2kmB5KxWuo80oAA33gZ=8JmRxmG3qGNxUg@mail.gmail.com>
In-Reply-To: <CAMbWs4-ra9mkBhUs2kmB5KxWuo80oAA33gZ=8JmRxmG3qGNxUg@mail.gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
Date: Mon, 20 Apr 2026 18:05:33 +0900
Message-ID: <CA+HiwqEtiTNV2v2P0HGa0B1TMNfmPweKXMZEOYPoQuFf3ZhsXQ@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: Richard Guo <guofenglinux@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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/CA%2BHiwqEtiTNV2v2P0HGa0B1TMNfmPweKXMZEOYPoQuFf3ZhsXQ%40mail.gmail.com>
Precedence: bulk

Hi Richard,

On Thu, Apr 16, 2026 at 3:05=E2=80=AFPM Richard Guo <guofenglinux@gmail.com=
> wrote:
> On Tue, Mar 3, 2026 at 11:32=E2=80=AFPM Richard Guo <guofenglinux@gmail.c=
om> wrote:
> > On Tue, Mar 3, 2026 at 10:03=E2=80=AFAM Richard Guo <guofenglinux@gmail=
.com> wrote:
> > > That is a good point I hadn't considered.  So I think the ideal fix i=
s
> > > 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.
>
> After a second look at this approach, I don't like it very much.  It
> manually constructed the new querytree, including Aggref,
> RangeTblEntry, and JsonConstructorExpr nodes, during planning,
> bypassing parse analysis entirely.  This is essentially repeating the
> parser's work by hand in the planner, which is fragile and prone to
> failing to handle all cases correctly.
>
> Maybe a simpler way is to keep the JSON_ARRAYAGG rewrite trick in the
> parser, as the current master does, but wrap the result in a COALESCE
> to handle the empty-set case.  We can preserve a copy of the user's
> original subquery in a new field of JsonConstructorExpr, and then
> ruleutils.c can use this field to deparse the original
> JSON_ARRAY(SELECT ...) syntax for view definitions.  You may think
> this would introduce extra transform work, but it wouldn't: the
> current master already transforms the original subquery to validate
> the single-column constraint, then throws the result away.  We simply
> keep it instead.
>
> I tried this idea and ended up with the attached.

Agreed that v4 is the better direction.

A couple of minor nits.

The comment on orig_query could say "not walked" a bit more helpfully, e.g.

Node       *orig_query;     /* for deparse only; not walked (func is) */

I also noticed that the comment for 'func' is incomplete as it is and
this change warrants an update. Maybe a bit long, but how about:

    Expr       *func;           /* expression producing the result:
                                 * Aggref/WindowFunc for *AGG,
                                 * CoalesceExpr for ARRAY_QUERY,
                                 * json[b]_xxx() call for remaining types *=
/

--=20
Thanks, Amit Langote