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
practice.
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,
>> https://tools.ietf.org/html/rfc4180 seems to specify CRLF end of lines.
>> The definition is evolving, eg https://www.w3.org/TR/tabular-data-model/
>> 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
disappointing.
> 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.
Indeed.
--
Fabien.
