Re: csv format for psql

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Daniel Verite <daniel@manitou-mail.org>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-10T02:58:10Z
Lists: pgsql-hackers
On Fri, Mar 9, 2018 at 3:18 PM, Daniel Verite <daniel@manitou-mail.org>
wrote:

> I think that the point of recordsep in unaligned mode is you can set it
>
to something that never appears in the data, especially when embedded
> newlines might be in the data. In CSV this is solved differently so
> we don't need it.


​I'd rather argue it from the standpoint that \copy doesn't use recordsep
nor fieldsep and thus neither should --csv; which is arguably a convenience
invocation of \copy that pipes to psql's stdout (and overcomes \copy's
single-line limitation - which I think still exists... - and inability to
use variables - does it?...).  COPY doesn't allow for changing the record
separator and the newline output is system-dependent.  I can accept the
same limitation with this feature.

I suppose the question is how many "COPY" options do we want to expose on
the command line, and how does it look?

I'll put a -1 on having a short option (-C or otherwise); "that is the way
its always been done" doesn't work for me here - by way of example "-a and
-A" is ill-advised; --echo-all does not seem important enough to warrant a
short option (especially not a lower-case one) and so the more useful
unaligned mode is forced into the secondary capital A position.

David J.

Commits

  1. Add CSV table output mode in psql.

  2. Reorganize format options of psql in alphabetical order

  3. Complete TODO item: