From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>,"Fabien COELHO" <coelho(at)cri(dot)ensmp(dot)fr>,"Michael Paquier" <michael(at)paquier(dot)xyz>,"Pg Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: csv format for psql |
Date: | 2018-11-26 17:47:32 |
Message-ID: | aa962740-c382-4d91-8516-3081c4e8355c@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> OK, reasonable arguments were made why not to allow multi-character
> separators. Should we then match the server and insist on a single-byte
> separator? It's a bit inconsistent if psql can be made to emit "csv"
> files that COPY can't read, especially when it's otherwise a subset
> of what COPY allows.
I seem to be the only one advocating to accept an Unicode
character here, and I won't insist on it.
There's still a minor annoyance to solve if we want to claim full
compatibility with COPY CSV: backslash followed by dot must be
quoted to avoid being interpreted as an end of data indicator.
A proposed fix is attached. print_csv_vertical() is left unchanged
because it's not possible currently to end up with \. alone
on a line with the expanded display: we'd need to allow
first for an empty field separator, I believe.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
Attachment | Content-Type | Size |
---|---|---|
psql-csv-backslash-dot-fix.txt | text/plain | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-11-26 18:09:43 | Re: pgsql: Integrate recovery.conf into postgresql.conf |
Previous Message | Andres Freund | 2018-11-26 17:46:36 | Re: allow online change primary_conninfo |