Re: csv format for psql

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: csv format for psql
Date: 2018-02-05 07:58:28
Message-ID: CAFj8pRBTckk=0hoTv4ucjeh=oT5X_cLoaB04fA8G37pu2HiewQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2018-01-31 14:09 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
> 2018-01-31 13:58 GMT+01:00 Daniel Verite <daniel(at)manitou-mail(dot)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
>>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-02-05 08:00:29 Re: csv format for psql
Previous Message Michael Paquier 2018-02-05 07:14:04 Typo with pg_multixact/offset in multixact.c