public inbox for [email protected]help / color / mirror / Atom feed
Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor> 3+ messages / 2 participants [nested] [flat]
* Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor> @ 2026-05-01 01:23 Richard Guo <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Richard Guo @ 2026-05-01 01:23 UTC (permalink / raw) To: Melanie Plageman <[email protected]>; +Cc: Nathan Bossart <[email protected]>; Tom Lane <[email protected]>; Amit Langote <[email protected]>; Vik Fearing <[email protected]>; [email protected]; [email protected]; [email protected]; Álvaro Herrera <[email protected]>; Heikki Linnakangas <[email protected]> On Fri, May 1, 2026 at 9:26 AM Richard Guo <[email protected]> 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. - Richard ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor> @ 2026-05-07 14:44 Ayush Tiwari <[email protected]> parent: Richard Guo <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Ayush Tiwari @ 2026-05-07 14:44 UTC (permalink / raw) To: Richard Guo <[email protected]>; +Cc: Melanie Plageman <[email protected]>; Nathan Bossart <[email protected]>; Tom Lane <[email protected]>; Amit Langote <[email protected]>; Vik Fearing <[email protected]>; [email protected]; [email protected]; [email protected]; Álvaro Herrera <[email protected]>; Heikki Linnakangas <[email protected]> Hi, On Fri, 1 May 2026 at 06:53, Richard Guo <[email protected]> wrote: > On Fri, May 1, 2026 at 9:26 AM Richard Guo <[email protected]> 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor> @ 2026-05-08 08:35 Richard Guo <[email protected]> parent: Ayush Tiwari <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Richard Guo @ 2026-05-08 08:35 UTC (permalink / raw) To: Ayush Tiwari <[email protected]>; +Cc: Melanie Plageman <[email protected]>; Nathan Bossart <[email protected]>; Tom Lane <[email protected]>; Amit Langote <[email protected]>; Vik Fearing <[email protected]>; [email protected]; [email protected]; [email protected]; Álvaro Herrera <[email protected]>; Heikki Linnakangas <[email protected]> On Thu, May 7, 2026 at 11:45 PM Ayush Tiwari <[email protected]> wrote: > 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) Nice catch. The empty-array Const was built with typmod -1, and the type input function was invoked with typmod -1, so any RETURNING length restriction was silently bypassed. I've pushed a fix that builds Const and calls the input function with the typmod of the non-empty COALESCE argument. - Richard ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-05-08 08:35 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-05-01 01:23 Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor> Richard Guo <[email protected]> 2026-05-07 14:44 ` Ayush Tiwari <[email protected]> 2026-05-08 08:35 ` Richard Guo <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox