Re: csv format for psql

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: csv format for psql
Date: 2018-03-10 06:45:03
Message-ID: alpine.DEB.2.20.1803100725250.19949@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Daniel,

About "-C", I'm fine if it is used and if it is not used, really. psql
begins to be quite full of one letter options, currently 34 of them, with
upper & lower cases and numbers included.

> The solution to set fieldsep automatically to ',' with
> \pset format csv is problematic.

I agree. I'm really advocating that --csv would set fieldsep, but manual
pset on format would still do what is expected, and only that, i.e. --csv
is NOT a simple shortcut for -P format=csv".

> Same problem on the command line. Options are evaluated left-to-right:
> $ psql --csv -F';'
> would work as expected, but
> $ psql -F';' --csv
> would not.

ISTM that having an option overriding another one after it is standard

I would be fine with that if --csv is documented as "setting format,
fieldsep and recordsep to default suited for outputting CSV".

Now this is just a personal opinion.

>> The "\n" eol style is hardcoded. Should it use "recordsep"? For instance,
>> seems to specify CRLF end of lines.
>> The definition is evolving, eg
>> accepts both "\r" and "\r\n". I do not like using windows eol, but I think
>> that it should be possible to do it, which is not the case with this
>> version.
> Interesting point. The output stream is opened in text mode so printing
> '\n' should generate LF on Unix, CR LF on Windows, and I think CR on MacOS.
> I think that's for the best.

I did not know that C's putc/printf/... would change output on sight on
different systems. I'm not sure I like it. It would still mean that one
cannot change the format to suits \r\n or \n at will, which is kind of

> recordsep in the unaligned mode doesn't play the role of a line ending
> because the last line is not finished by recordsep.

It could just be with CSV format? As you point out, there is already an
exception with the separator is '\0'. Note that the last line of a CSV
file may or may not end with \n or \r\n, according to specs.

>> I'd suggest that tests should include more types, not just strings. I
>> would suggest int, float, timestamp, bytea, an array (which uses , as a
>> separator), json (which uses both " and ,)...
> I'll do but the printout code is type-agnostic so it's not supposed
> to make a difference compared to mere literals.

Sure, but it seems better to actually see that it works properly for non
trivial cases.

> Cases with NULLs are missing though, I'll go add some too.



In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-03-10 06:49:45 Re: csv format for psql
Previous Message Tom Lane 2018-03-10 04:40:16 Re: constraint exclusion and nulls in IN (..) clause