| 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: | Whole Thread | Raw Message | 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 |