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

From David G. Johnston
Subject Re: csv format for psql
Date
Msg-id CAKFQuwZKtjuGgOW=ZEn9Ku+2SxVkf1T13cU-NXHv9K3fkUL-Gg@mail.gmail.com
Whole thread Raw
In response to Re: Re: csv format for psql  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: csv format for psql  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: csv format for psql  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
On Wednesday, March 28, 2018, Pavel Stehule <pavel.stehule@gmail.com> wrote:

Are there some possible alternatives?

Given the date and the fact that the cf end is 3 days away, the proposed short term alternative is Daniel's version, that I feel is reasonable. Ok, people have to do two pset to get comma-separated csv, otherwise they get pipe-separated csv in one pset.


Could someone post how captions, rows-only, and footer pset settings factor into this?  Specifically are they fixed to on/off or will they hide/show if users request them explicitly?

My take on this is that --csv mode is/should be an alternate output mode from the existing pset controlled one, and functions basically like "\copy to stdout" and all echoing and metadata outputs are disabled and only query results, with header and the user specified delimiter, are output.  No control other than the delimiter seems to be provided in the current design but that could be expanded upon.  In that specification the existing fieldsep argument that is tied to pset should not be used and something like --csv-fieldsep should be provided (I like the prefixing to tie the option lexically to the master --csv option).

David J.

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary
Next
From: Keiko Oda
Date:
Subject: Re: Trigger file behavior with the standby