|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
PostgreSQL-powered mailer: http://www.manitou-mail.org
|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|