Re: csv format for psql
Daniel Verite <daniel@manitou-mail.org>
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Michael Paquier" <michael@paquier.xyz>
Cc: "Fabien COELHO" <coelho@cri.ensmp.fr>,"PostgreSQL Hackers"
<pgsql-hackers@postgresql.org>
Date: 2018-11-11T14:51:27Z
Lists: pgsql-hackers
Michael Paquier wrote: > - The experience is confusing, as the psql format uses different options > than the backend to do the same things: > -- tuples_only instead of HEADER. > -- fieldsep_csv instead of DELIMITER > -- null is an equivalent of the one with the same name, which is > actually consistent. > -- encoding is also an equivalent of ENCODING. That conveniently ignores the fact that "\pset format somename" as a command doesn't take any additional option, contrary to COPY. We can't do \pset format csv (delimiter=';') If we choosed "delimiter" as an option name, it would have to exist within 20 other names in the \pset namespace and then it would be too vague, whereas "fieldsep_csv" makes it clear what it applies to. "tuples_only" is preexisting, and I don't see how the comment that it's not called "header" could be actionable. Overall, you seem to posit that we should mimic the entire COPY TO interface to implement 'psql --csv'. But the starting point is that 'psql --csv' is just a slightly different (safer) variant of 'psql -At', which is not concerned at all with being consistent with COPY. The model of the csv output format is the unaligned output format, it's just not COPY. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
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