Re: [PATCH] Reject ENCODING option for COPY TO FORMAT JSON

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [PATCH] Reject ENCODING option for COPY TO FORMAT JSON
Date: 2026-04-29 16:49:24
Message-ID: CAJTYsWXtmAAYCymBFLPTgp6TJTOsrsV2KcmzjQWS+7PLi_r_Ng@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, 20 Apr 2026 at 20:31, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
wrote:

> Hi,
>
>>
>> On Mon, 20 Apr 2026 at 19:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>
>
>> Seems to me the correct thing here is to make it work like the other
>>> cases, ie perform pg_server_to_any(). I have exactly no sympathy for
>>> the argument about the RFC saying it must be UTF-8, not least because
>>> that's not in fact what is implemented (what if the server encoding
>>> isn't UTF-8?).
>>>
>>
>> Agreed. I initially thought rejecting the option was the safer route
>> given the RFC, but as you pointed out, we aren't enforcing
>> UTF-8 strictly on the server side anyway.
>>
>>
>>> Rejecting this option altogether doesn't improve anything, not
>>> functionally, not specs-compliance-wise, nor according to the
>>> principle of least surprise.
>>>
>>
>> Makes sense. Implementing the conversion properly
>> keeps JSON format consistent with how the text and CSV formats behave.
>>
>>>
>>> No, you don't get to punt this till later. Once we ship v19 there's
>>> going to be a strong expectation of backwards compatibility.
>>>
>>> The idea of sending UTF-8 to a client that's set client_encoding to
>>> something else would be risible, if it weren't a security hazard.
>>>
>>
>> I agree sending unconverted bytes to a mismatched
>> client encoding is clearly a security hazard that needs addressing. Did
>> not consider the backward compatibility part, my bad.
>>
>> Was trying out adding pg_server_to_any() to the json_buf after
>> composite_to_json() returns,
>> correctly covering both explicit ENCODING option specifications and
>> implicit client_encoding mismatches.
>>
>> Let me send a patch with code and associated test cases.
>>
>>
> Attached patch with round trip test case. Please review and let me
> know if it's in the right direction.
>

I have registered this patch set in the CommitFest for tracking:
https://commitfest.postgresql.org/patch/6700/

Please let me know if the patch looks good, and if I need to add it
in the open items list for PG 19.

Regards,
Ayush

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-04-29 17:32:14 Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects
Previous Message SATYANARAYANA NARLAPURAM 2026-04-29 16:35:44 Limit GRAPH_TABLE path combinations to prevent memory exhaustion