Re: csv format for psql
От | Fabien COELHO |
---|---|
Тема | Re: csv format for psql |
Дата | |
Msg-id | alpine.DEB.2.20.1804010812480.24640@lancre обсуждение исходный текст |
Ответ на | Re: csv format for psql (Isaac Morland <isaac.morland@gmail.com>) |
Ответы |
Re: csv format for psql
|
Список | pgsql-hackers |
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. -- Fabien.
В списке pgsql-hackers по дате отправления: