|From:||"Daniel Verite" <daniel(at)manitou-mail(dot)org>|
|To:||"Michael Paquier" <michael(at)paquier(dot)xyz>|
|Cc:||"Fabien COELHO" <coelho(at)cri(dot)ensmp(dot)fr>,"PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: csv format for psql|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
PostgreSQL-powered mailer: http://www.manitou-mail.org
|Next Message||chenhj||2018-11-11 17:10:32||Re:Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock|
|Previous Message||Tom Lane||2018-11-11 04:38:13||Re: Uninterruptible long planning of a query with too many WHERE clauses|