MIME-Version: 1.0
References: <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>
 <CA+HiwqEtiTNV2v2P0HGa0B1TMNfmPweKXMZEOYPoQuFf3ZhsXQ@mail.gmail.com>
 <CAMbWs49tDE_niKLr4mzsa2BkX7fkWrorBzWheKTBziZ7z9-AuQ@mail.gmail.com>
 <CAMbWs48KEdgyJhxCOysaRdRJ5NzPObUET+5XbvyiqDfqyABEwg@mail.gmail.com>
 <485641.1776738632@sss.pgh.pa.us> <CAMbWs4_vqNEcHpvKFeFxfRoisrvw6yJ3styhS-arQDHZirw5cQ@mail.gmail.com>
 <CAMbWs49ps9eGWvkwc64ytUxdK0s-=xdFjtf64WyGp65EgTZ_LQ@mail.gmail.com>
 <aevLYeoSSgiwEiO-@nathan> <CAAKRu_YU542L_+_H1VFSTtLnj4Yo=GcXykyiw_6GZZiOEt5mVA@mail.gmail.com>
 <CAMbWs4_n8f2kPHkEw=ToZMh2FAzc6BDXq9uND-iY9-MB_fE_Vg@mail.gmail.com> <CAMbWs4_TLsrWftz=TzpT9=fp=01LAZWRmdDLUMA9qTzMtXZwig@mail.gmail.com>
In-Reply-To: <CAMbWs4_TLsrWftz=TzpT9=fp=01LAZWRmdDLUMA9qTzMtXZwig@mail.gmail.com>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Thu, 7 May 2026 20:14:52 +0530
Message-ID: <CAJTYsWXPYqa58YXrU+SQMVonsAhjLS46HNUMU=wO5zm9MgY3_g@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: Melanie Plageman <melanieplageman@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, 
	Tom Lane <tgl@sss.pgh.pa.us>, Amit Langote <amitlangote09@gmail.com>, 
	Vik Fearing <vik@postgresfriends.org>, lukas.eder@gmail.com, 
	pgsql-bugs@lists.postgresql.org, rmt@lists.postgresql.org, 
	=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>, 
	Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: multipart/alternative; boundary="000000000000449cdf06513b535b"
Archived-At: <https://www.postgresql.org/message-id/CAJTYsWXPYqa58YXrU%2BSQMVonsAhjLS46HNUMU%3DwO5zm9MgY3_g%40mail.gmail.com>
Precedence: bulk

--000000000000449cdf06513b535b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,


On Fri, 1 May 2026 at 06:53, Richard Guo <guofenglinux@gmail.com> wrote:

> On Fri, May 1, 2026 at 9:26=E2=80=AFAM Richard Guo <guofenglinux@gmail.co=
m> wrote:
> > Thank you, Nathan and Melanie.  I now have two of the three RMT
> > approvals, so I believe I'm good to go.  Will commit this shortly.
>
> Committed.
>

While looking at the JSON_ARRAY(query) empty-set fix, I noticed what
looks like a typmod issue in the new empty-array fallback.

I understand from this discussion that returning [] for an empty
JSON_ARRAY(query) input is intentional and required by SQL/JSON.  This
report is
about the RETURNING typmod not being enforced on that new [] fallback.

The non-empty query form enforces the RETURNING typmod:

  SELECT JSON_ARRAY(SELECT 1 RETURNING varchar(1));
  ERROR:  value too long for type character varying(1)

but the empty query form returns a value that does not fit the declared
type:

  SELECT JSON_ARRAY(SELECT 1 WHERE false RETURNING varchar(1));
   json_array
  ------------
   []
  (1 row)

The same inconsistency is visible through a view: the column is stored as
varchar(1), and pg_get_viewdef() shows RETURNING character varying(1), but
executing the view can still return the two-character value [].

The issue appears to be in transformJsonArrayQueryConstructor(): the
COALESCE
fallback builds the empty-array constant with typmod -1, and later
eval_const_expressions() replaces JSCTOR_JSON_ARRAY_QUERY with this
pre-built
func expression.  At that point the JsonConstructorExpr wrapper's RETURNING
typmod is no longer enough to enforce varchar(1).

I think the right fix is probably to make the executable expression stored
in
func carry the RETURNING typmod coercion.  This would also match the
direction
sketched earlier in the thread, where the fallback was described as
'[]'::[RETURNING_TYPE].  For example, coerceJsonFuncExpr() could notice
same-type/different-typmod cases, and transformJsonArrayQueryConstructor()
could
apply it to the COALESCE expression before storing that expression in the
JSCTOR_JSON_ARRAY_QUERY node.

Regards,
Ayush

--000000000000449cdf06513b535b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,<div><br></div></div><br><div class=3D=
"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Fri, 1 May 2026 at 06:53, Richard Guo &lt;<a href=3D"mailto:guofenglinux@=
gmail.com">guofenglinux@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On Fri, May 1, 2026 at 9:26=E2=80=AFAM Ric=
hard Guo &lt;<a href=3D"mailto:guofenglinux@gmail.com" target=3D"_blank">gu=
ofenglinux@gmail.com</a>&gt; wrote:<br>
&gt; Thank you, Nathan and Melanie.=C2=A0 I now have two of the three RMT<b=
r>
&gt; approvals, so I believe I&#39;m good to go.=C2=A0 Will commit this sho=
rtly.<br>
<br>
Committed.<br></blockquote><div><br></div>While looking at the JSON_ARRAY(q=
uery) empty-set fix, I noticed what<br>looks like a typmod issue in the new=
 empty-array fallback.<br><br>I understand from this discussion that return=
ing [] for an empty<br>JSON_ARRAY(query) input is intentional and required =
by SQL/JSON.=C2=A0 This report is<br>about the RETURNING typmod not being e=
nforced on that new [] fallback.<br><br>The non-empty query form enforces t=
he RETURNING typmod:<br><br>=C2=A0 SELECT JSON_ARRAY(SELECT 1 RETURNING var=
char(1));<br>=C2=A0 ERROR: =C2=A0value too long for type character varying(=
1)<br><br>but the empty query form returns a value that does not fit the de=
clared type:<br><br>=C2=A0 SELECT JSON_ARRAY(SELECT 1 WHERE false RETURNING=
 varchar(1));<br>=C2=A0 =C2=A0json_array<br>=C2=A0 ------------<br>=C2=A0 =
=C2=A0[]<br>=C2=A0 (1 row)<br><br>The same inconsistency is visible through=
 a view: the column is stored as<br>varchar(1), and pg_get_viewdef() shows =
RETURNING character varying(1), but<br>executing the view can still return =
the two-character value [].<br><br>The issue appears to be in transformJson=
ArrayQueryConstructor(): the COALESCE<br>fallback builds the empty-array co=
nstant with typmod -1, and later<br>eval_const_expressions() replaces JSCTO=
R_JSON_ARRAY_QUERY with this pre-built<br>func expression.=C2=A0 At that po=
int the JsonConstructorExpr wrapper&#39;s RETURNING<br>typmod is no longer =
enough to enforce varchar(1).<br><br>I think the right fix is probably to m=
ake the executable expression stored in<br>func carry the RETURNING typmod =
coercion.=C2=A0 This would also match the direction<br>sketched earlier in =
the thread, where the fallback was described as<br>&#39;[]&#39;::[RETURNING=
_TYPE].=C2=A0 For example, coerceJsonFuncExpr() could notice<br>same-type/d=
ifferent-typmod cases, and transformJsonArrayQueryConstructor() could<br>ap=
ply it to the COALESCE expression before storing that expression in the<br>=
JSCTOR_JSON_ARRAY_QUERY node.<br><br>Regards,<br><div>Ayush=C2=A0</div></di=
v></div>

--000000000000449cdf06513b535b--