Re: [HACKERS] proposal: psql command \graw

2018-01-15 18:40 GMT+01:00 Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>:

> Hi!
>
> On Mon, Dec 4, 2017 at 6:42 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>> 2017-12-04 9:29 GMT+01:00 Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>:
>>
>>> On Mon, Dec 4, 2017 at 11:21 AM, Alexander Korotkov <
>>> a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>>>
>>>> The problem is that it's hard to read arbitrary formatted psql output
>>>> from external program (not just gnuplot, but even especially written
>>>> script). I made my scripts read few variations, but it doesn't look
>>>> feasible to read all the combinations. For sure, it's possible to set
>>>> format options inside macro, but then it would affect psql format options
>>>> after execution.
>>>>
>>>> This is why I think only one \graw option is just fine, because it
>>>> produces stable machine-readable output.
>>>>
>>>
>>> Oh, I just get that in current state of \graw doesn't produce good
>>> machine-readable output.
>>>
>>> # select '|', '|' \graw
>>> |||
>>>
>>> Column separator is character which can occur in values, and values
>>> aren't escaped. Thus, reader can't correctly divide values between columns
>>> in all the cases. So, I would rather like to see \graw to output in csv
>>> format with proper escaping.
>>>
>>
>> current \graw implementation is pretty minimalistic
>>
>> It is interesting topic - the client side csv support.
>>
>> It can simplify lot of things
>>
>
> So, I see there is no arguing yet that exporting dataset from psql into a
> pipe in machine-readable format (presumably csv) would be an useful feature.
> Are you going to revise your patch that way during this commitfest?
> I'm marking this patch as "waiting for author" for now.
>

I hope so lot of people invite CSV support on client side. Some like:

psql -c "SELECT * FROM pg_class" --csv --header > pg_class.csv

Client side CSV formatting is significantly better idea. Unfortunately
there are not clean how to do it. The basic question is: can we have 2
codes for CSV - server side/client side? If yes, then implementation should
be trivial. If not, then I have not any idea.

We are able to generate html/tex/markdown formats on client side. CSV is
more primitive, but much more important data format, so it should not be a
problem. But I remember some objections related to code duplication.

Regards

Pavel

>
> ------
> Alexander Korotkov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>