From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: csv format for psql |
Date: | 2018-03-08 08:29:06 |
Message-ID: | alpine.DEB.2.20.1803080840240.2916@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I.e. really generate some csv from the data in just one option, not many.
>>
>> But this is obviously debatable.
>
> I suspect we'll get requests for an all-JSON option, HTML tables,
> etc., assuming we don't have them already.
I would definitely be fine with --html (which indeed already exists) &
--json (which does not, but could some day) as long options.
> I'm hoping we can have that all in one framework.
ISTM that it is more or less the case if an option simply presets a bunch
of existing table output options which is an existing framework.
> I get that setting each of tuples_only, fieldsep, recordsep, etc.
> might be a bit of a lift for some users, but it's not clear how we'd
> make a sane default that made choices among those correct for enough
> users. For example, do we know that we want tuples_only behavior by
> default? A lot of people's CSV tools assume a header row.
If there is a possible disagreement on one option, then let it out and use
the corresponding short option if needed?
Tuple only:
psql --csv -t -c 'TABLE foo' -o foo.csv
With title headers:
psql --csv -c 'TABLE foo' -o foo.csv
Would be okay.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-03-08 08:40:59 | Re: csv format for psql |
Previous Message | David Gould | 2018-03-08 08:11:34 | Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate. |