Re: csv format for psql

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
Date: 2018-11-11 14:51:27
Message-ID: df01044f-e47c-491c-80d5-915fcf230ecb@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
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