On Fri, May 1, 2026 at 9:26 AM Richard Guo <guofenglinux@gmail.com> 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
