From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com>, Davin Shearer <davin(at)apache(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Emitting JSON to file using COPY TO |
Date: | 2023-12-04 14:25:04 |
Message-ID: | 41dcba92-1075-e5e5-cb99-36711abf6cec@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On 2023-12-04 Mo 08:37, Joe Conway wrote:
> On 12/4/23 07:41, Andrew Dunstan wrote:
>>
>> On 2023-12-03 Su 20:14, Joe Conway wrote:
>>> (please don't top quote on the Postgres lists)
>>>
>>> On 12/3/23 17:38, Davin Shearer wrote:
>>>> " being quoted as \\" breaks the JSON. It needs to be \". This has
>>>> been my whole problem with COPY TO for JSON.
>>>>
>>>> Please validate that the output is in proper format with correct
>>>> quoting for special characters. I use `jq` on the command line to
>>>> validate and format the output.
>>>
>>> I just hooked existing "row-to-json machinery" up to the "COPY TO"
>>> statement. If the output is wrong (just for for this use case?),
>>> that would be a missing feature (or possibly a bug?).
>>>
>>> Davin -- how did you work around the issue with the way the built in
>>> functions output JSON?
>>>
>>> Andrew -- comments/thoughts?
>>
>> I meant to mention this when I was making comments yesterday.
>>
>> The patch should not be using CopyAttributeOutText - it will try to
>> escape characters such as \, which produces the effect complained of
>> here, or else we need to change its setup so we have a way to inhibit
>> that escaping.
>
>
> Interesting.
>
> I am surprised this has never been raised as a problem with COPY TO
> before.
>
> Should the JSON output, as produced by composite_to_json(), be sent
> as-is with no escaping at all? If yes, is JSON somehow unique in this
> regard?
Text mode output is in such a form that it can be read back in using
text mode input. There's nothing special about JSON in this respect -
any text field will be escaped too. But output suitable for text mode
input is not what you're trying to produce here; you're trying to
produce valid JSON.
So, yes, the result of composite_to_json, which is already suitably
escaped, should not be further escaped in this case.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | John DeSoi | 2023-12-04 15:40:46 | Re: libpq crashing on macOS during connection startup |
Previous Message | Joe Conway | 2023-12-04 13:37:23 | Re: Emitting JSON to file using COPY TO |
From | Date | Subject | |
---|---|---|---|
Next Message | Drouvot, Bertrand | 2023-12-04 14:37:48 | Re: Synchronizing slots from primary to standby |
Previous Message | Thomas wen | 2023-12-04 14:02:06 | 回复: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) |