From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Joel Jacobson" <joel(at)compiler(dot)org> |
Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: New "raw" COPY format |
Date: | 2024-10-16 16:34:13 |
Message-ID: | d3313604-fbdd-483f-9c29-aceaf491f949@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joel Jacobson wrote:
> However, I thinking rejecting such column data seems like the
> better alternative, to ensure data exported with COPY TO
> can always be imported back using COPY FROM,
> for the same format.
On the other hand, that might prevent cases where we
want to export, for instance, a valid json array:
copy (select json_agg(col) from table ) to 'file' RAW
This is a variant of the discussion in [1] where the OP does:
copy (select json_agg(row_to_json(t)) from <query> t) TO 'file'
and he complains that both text and csv "break the JSON".
That discussion morphed into a proposed patch adding JSON
format to COPY, but RAW would work directly as the OP
expected.
That is, unless <query> happens to include JSON fields with LF/CRLF
in them, and the RAW format says this is an error condition.
In that case it's quite annoying to make it an error, rather than
simply let it pass.
[1]
https://postgr.es/m/CALvfUkBxTYy5uWPFVwpk_7ii2zgT07t3d-yR_cy4sfrrLU=kcg@mail.gmail.com
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-10-16 16:41:42 | Re: Misleading error "permission denied for table" |
Previous Message | Tom Lane | 2024-10-16 16:26:48 | Re: ECPG cleanup and fix for clang compile-time problem |