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

From David G. Johnston
Subject Re: csv format for psql
Date
Msg-id CAKFQuwbzfyki+0tBHuXmaYQFX5vBHBOnQ-caNda6i5ssteBT0A@mail.gmail.com
Whole thread Raw
In response to Re: Re: csv format for psql  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: csv format for psql  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
On Wednesday, March 28, 2018, Fabien COELHO <coelho@cri.ensmp.fr> wrote:


And if we introduce csv-specific fieldsep, then we multiply this wrong design. The fix in this direction is renaming fieldsep to fieldsep-unaliagn - but it is probably too big change too. So this design is nothing what I can mark as good solution.

Good, we somehow agree on something!

I can live with because it is much better than using pipe as separator for csv, and because real impact is small - for almost people it will be invisible - but have not good feeling from it.

Concretely...I'm in favor of the "\pset fieldsep_csv ," solution and csv format should always use its existing value.  Teach \pset fieldsep to fail if the current format is csv.  Being able to specify the csv fieldsep like  "\pset format csv ;" would be a plus.

Unaligned format could grow its own fieldsep if it wanted to but it can also just use the default provided fieldsep var whose default value is pipe.  If it did grow one it would need to understand "not set" in order to preserve existing behavior.  We don't have that problem with csv.

I don't believe we can modify fieldsep without causing unwanted grief.

David J.

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Using base backup exclusion filters to reduce data transferredwith pg_rewind
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] why not parallel seq scan for slow functions