2018-01-31 14:09 GMT+01:00 Pavel Stehule <pavel.steh...@gmail.com>:
>
>
> 2018-01-31 13:58 GMT+01:00 Daniel Verite <dan...@manitou-mail.org>:
>
>> Pavel Stehule wrote:
>>
>> > This format is too important, so some special short or long option can
>> be
>> > practical (it will be printed in help)
>> >
>> > some like --csv
>>
>> I guess -C/--csv could be used, like there already is -H/--html.
>>
>> > I found one issue - PostgreSQL default field separator is "|". Maybe
>> good
>> > time to use more common "," ?
>> >
>> > Or when field separator was not explicitly defined, then use "," for
>> CSV,
>> > and "|" for other. Although it can be little bit messy
>>
>> Currently there's a strong analogy between the unaligned
>> mode and csv mode. In particular they use the existing pset
>> variables fieldsep, fieldsep_zero, recordsep, recordsep_zero
>> in the same way. If we want to make csv special with regard
>> to the delimiters, that complicates the user interface
>> For instance if fieldsep was changed automatically by
>> \pset format csv, it's not obvious if/when we should switch it
>> back to its previous state, and how the fieldsep switch done
>> automatically would mix or conflict with other \pset
>> commands issued by the user.
>> Or we need to duplicate these variables. Or duplicate
>> only fieldsep, having a fieldsep_csv, leaving out the
>> other variables and not being as close to the unaligned
>> mode.
>> These options don't appeal to me much compared
>> to the simplicity of the current patch.
>>
>> Also, although the comma is the separator defined by the
>> RFC4180 and the default for COPY CSV, people also use the
>> semicolon extensively (because it's what Excel does I guess),
>> which somehow mitigates the importance of comma as the
>> default value.
>>
>>
> The functionality is clean and great - default setting "|" is less. I have
> not strong opinion about it and I understand to your arguments. Has anybody
> some idea?
>
two other ideas from me
1. currently \pset format xxx command has not any other parameters. Other
optional parameters can be set of possible attributes like {, ; | \t
header_off escape_all}. If this set will be known by tabcomplete, then it
can be very friendly and I don't think so code will be more complex than in
your proposal (long options can be "--csv --csv-options=", header_off" )
some like "\pset format csv , header_off
or just limited variant with only field separator specification
\pset format csv ;
2. if we support csv format, then we can introduce \gcsv xxx | gnuplot ....
It is just idea.
@1 is much more interesting than @2
Regards
Pavel
>
> Regards
>
> Pavel
>
>
>>
>> Best regards,
>> --
>> Daniel Vérité
>> PostgreSQL-powered mailer: http://www.manitou-mail.org
>> Twitter: @DanielVerite
>>
>
>
