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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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:
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