Re: csv format for psql

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.

In response to

Responses

Browse pgsql-hackers by date

  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.