Re: csv format for psql - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: csv format for psql
Date
Msg-id alpine.DEB.2.20.1804010812480.24640@lancre
Whole thread Raw
In response to Re: csv format for psql  (Isaac Morland <isaac.morland@gmail.com>)
Responses Re: csv format for psql
List 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 by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath
Next
From: David Rowley
Date:
Subject: Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath