Re: Fix missing FORMAT when deparsing JSON_ARRAY(query)

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Ewan Young <kdbase(dot)hack(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Richard Guo <guofenglinux(at)gmail(dot)com>
Subject: Re: Fix missing FORMAT when deparsing JSON_ARRAY(query)
Date: 2026-07-23 08:23:27
Message-ID: 250D39D7-E1EF-4099-B889-B75DF3E2DF33@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Jul 23, 2026, at 15:25, Ewan Young <kdbase(dot)hack(at)gmail(dot)com> wrote:
>
> On Wed, Jul 22, 2026 at 2:22 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>>
>> Hi,
>>
>> While testing "[8d829f5a0] Fix JSON_ARRAY(query) empty set handling and view deparsing”, I found that the departing may 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 deparsed SELECT 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 JsonFormat field 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2026-07-23 08:25:22 Re: log_postmaster_stats
Previous Message Anthonin Bonnefoy 2026-07-23 08:19:04 Re: Fix error handling in getCopyDataMessage and pqFunctionCall3