Re: csv format for psql

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: csv format for psql
Дата
Msg-id CAFj8pRAB8D3=MGQ7xYqPb4-Nw52wgvBk+EDyzmaGRPJn9knVJg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: csv format for psql  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: csv format for psql  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: csv format for psql  ("Daniel Verite" <daniel@manitou-mail.org>)
Список pgsql-hackers


2018-04-01 8:30 GMT+02:00 Fabien COELHO <coelho@cri.ensmp.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: some last patches breaks plan cache