Re: csv format for psql

2018-04-01 8:30 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> Hello Isaac,
>
> Personnaly I do not have any problem with CSV defaulting to '|' separator,
>>> given that anyway people often use anything but a comma for the purpose,
>>> including '|'.
>>>
>>> However Pavel wants to block the patch on this point. Too bad.
>>>
>>
>> OK, mostly trying to avoid commenting because I doubt I have much to add.
>> But. If I ask for CSV and don't specify any overrides, I expect to get
>> "C"omma separated values, not some other character. More specifically, if I
>> say --csv I expect to get files that are identical with what I would get if
>> I used COPY ... CSV.
>>
>
> My summary was incomplete. The --csv option implementation by Daniel
> already does that.
>
> The issue Pavel is complaining about is that in interactive mode "\pset
> format csv" does not do the same: it triggers the csv-rule string-escaping
> mechanism, but does not reset the "fieldsep" variable (eh, it sets the
> "format" variable) so the default separator under this interactive use is
> "|" if the "fieldsep" variable is shared.
>
> I have suggested a "\csv" interactive command to set both as a convenient
> shorthand for "\pset format csv & \pset fieldsep ','", similarly to --csv,
> but Pavel still wants "\pset format csv" to trigger the full csv output.
>
> A consequence I forgot about adding "fieldsep_csv", is that it probably
> has to duplicate the "_zero" ugly hack to be consistent with existing
> "*sep" variables, or else be inconsistent. Sigh.
>

there are not any relation between fieldsep_csv and fieldsep_zero.

The base of this issue is in wrong concept of fieldsep. It is based on idea
so one value can be good enough for all formats. It is worked when all
formats that used this variable is ONE format - unaligned.

similar issue is with tuplesonly option - see Isaac's mail.

For different formats the different defaults are more consistent - the
other formats does it - doesn't use fieldsep - but it lost internal
consistency, because its does quietly.

We can have different ideas about users's expectations - but we should to
share opinion, so correct solution should be consistent. If I choose some
format, then behave should be same without dependency on activation
mechanism.

so \csv should be same like \pset format csv or --csv.

I don't share option so CSV format should be exactly same like CSV COPY.
COPY is designed for backups - and header is not too important there. When
I seen some csv, then there usually header was used.

If I can search some precedent, then it is \pset linestyle and \pset
unicode_*** options.

so we can to have

\pset format xxx

and set of local possibly changed defaults

\pset csv_fieldsep ,
\pset csv_tuplesonly on
\pset unaligned_fieldsep |
\pset unaligned_tuplesonly off

the fieldsep, tuplesonly can be just links to currently used ****_fieldsep
and ****_tuplesonly

This is consistent - defaults can be correct for Isaac, and I can paste to
my .psqlrc

\pset csv_tuplesonly off

and the semantic is clean, and this option will be active just for csv, and
doesn't depend on current format - so it can be used in .psqlrc

When it is works well for linestyle, then it can works for some other too

Regards

Pavel

>
> --
> Fabien.
>