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
