Re: Fix missing FORMAT when deparsing JSON_ARRAY(query) - Mailing list pgsql-hackers

From Ewan Young
Subject Re: Fix missing FORMAT when deparsing JSON_ARRAY(query)
Date
Msg-id CAON2xHO8_boiXKutz=F_vHGeP+DM1Um+B27BaQsDxw_ZDuY7ag@mail.gmail.com
Whole thread
In response to Re: Fix missing FORMAT when deparsing JSON_ARRAY(query)  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
On Thu, Jul 23, 2026 at 4:24 PM Chao Li <li.evan.chao@gmail.com> wrote:
>
>
>
> > On Jul 23, 2026, at 15:25, Ewan Young <kdbase.hack@gmail.com> wrote:
> >
> > On Wed, Jul 22, 2026 at 2:22 PM Chao Li <li.evan.chao@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> While testing "[8d829f5a0] Fix JSON_ARRAY(query) empty set handling and view deparsing”, I found that the
departingmay omit the FORMAT JSON clause. 
> >>
> >> Here is a simple repro:
> >> ```
> >> evantest=# create view v as
> >> evantest-#   select json_array(select '{"a": 1}'::text format json) as j;
> >> CREATE VIEW
> >> evantest=# select * from v;
> >>     j
> >> ------------
> >> [{"a": 1}]
> >> (1 row)
> >>
> >> evantest=# select pg_get_viewdef('v'::regclass, true);
> >>                              pg_get_viewdef
> >> ---------------------------------------------------------------------------
> >>  SELECT JSON_ARRAY( SELECT '{"a": 1}'::text AS text RETURNING json) AS j;
> >> (1 row)
> >>
> >> evantest=# select pg_get_viewdef('v'::regclass, false);
> >>                              pg_get_viewdef
> >> ---------------------------------------------------------------------------
> >>  SELECT JSON_ARRAY( SELECT '{"a": 1}'::text AS text RETURNING json) AS j;
> >> (1 row)
> >>
> >> evantest=# SELECT JSON_ARRAY( SELECT '{"a": 1}'::text AS text RETURNING json) AS j;
> >>       j
> >> ----------------
> >> ["{\"a\": 1}"]
> >> (1 row)
> >> ```
> >>
> >> As shown above, I defined the view with FORMAT JSON, but the deparsed SQL has lost that clause. Running the
deparsedSELECT produces a different result from selecting from the view because FORMAT JSON is missing. 
> >>
> >> Currently, JsonConstructorExpr does not store the JsonFormat information. To fix this problem, we need to add a
JsonFormatfield to JsonConstructorExpr. Please see the attached patch for details. 
> >>
> >> With the fix:
> >> ```
> >> evantest=# select pg_get_viewdef('v'::regclass, true);
> >>                                    pg_get_viewdef
> >> ---------------------------------------------------------------------------------------
> >>  SELECT JSON_ARRAY( SELECT '{"a": 1}'::text AS text FORMAT JSON RETURNING json) AS j;
> >> (1 row)
> >>
> >> evantest=# SELECT JSON_ARRAY( SELECT '{"a": 1}'::text AS text FORMAT JSON RETURNING json) AS j;
> >>     j
> >> ------------
> >> [{"a": 1}]
> >> (1 row)
> >> ```
> >
> > Thanks for the patch — I reviewed and tested it, and it looks correct.
> >
>
> Thank you very much for the review.
>
> > One thing that seems missing:  since JsonConstructorExpr is stored in
> > pg_rewrite (and in SQL-function bodies), adding a field changes the
> > stored node representation,
> > so this should bump CATALOG_VERSION_NO?
> >
>
> You are right, CATALOG_VERSION_NO needs to be bumped. As a general rule, however, the committer will do that before
pushing,so submitted patches should never touch CATALOG_VERSION_NO. 

Thanks for explaining.
Other than that, the patch looks good to me.

>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>


--
Regards,
Ewan Young



pgsql-hackers by date:

Previous
From: Jakub Wartak
Date:
Subject: Re: log_postmaster_stats
Next
From: Rafia Sabih
Date:
Subject: Re: Bypassing cursors in postgres_fdw to enable parallel plans