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
-
Add CSV table output mode in psql.
- aa2ba50c2c13 12.0 landed
-
Reorganize format options of psql in alphabetical order
- add9182e5908 12.0 landed
-
Complete TODO item:
- 862b20b38228 8.0.0 cited