Re: [HACKERS] proposal: psql command \graw

On Fri, Dec 1, 2017 at 6:36 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Dec 1, 2017 at 12:16 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > On Sat, Nov 11, 2017 at 12:57 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >> 2017-11-10 16:38 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
> >>> So I switched the patch to "ready for committer".
> >>
> >> Thank you very much
> >
> > Patch moved to CF 2018-01 with same status: ready for committer.
>
> I vote to reject this patch. It doesn't do anything that you can't
> already do; it just adds some syntactic sugar. And that syntactic
> sugar saves only a handful of keystrokes. If you want unaligned,
> tuples-only mode, you can set it in 5 keystrokes:
>
> rhaas=# \a\t
> Output format is unaligned.
> Tuples only is on.
>
> If you use this command, it takes 4 keystrokes; instead of ending your
> command with a semicolon (1 character) you end it with \graw (5
> characters).
>
> Now, granted, \graw lets you set those options for a single command
> rather than persistently, but I'm just not very interested in having a
> bunch of \g<whatever> options that enable various combinations of
> options. Soon we'll have a thicket of \g variants that force
> whichever combinations of options particular developers like to use,
> and if \graw is any indication, the \g<whatever> variant won't
> necessarily look anything like the normal way of setting those
> options. And that's not easy to fix, either: \graw could be spelled
> \gat since it forces \a on and \t on, but somebody's bound to
> eventually propose a variant that sets an option that has no
> single-character shorthand.
>

For sure, bunch of \g<wahtever> options don't look interesting. But I
think \graw option would be quite useful if even it would be the only form
of \g<wahtever> forever.

Our command line client psql have two great features:
1. Output format customization including boards, separators, spacing, title
and so on
2. Ability to export data into files or pipes. It's even more powerful
with macros enabling you doing cool things with your data in few
keystokes. I've couple of examples in my blog, but for sure it's possible
to do much more.
http://akorotkov.github.io/blog/2015/08/26/psql-gdb-attach/
http://akorotkov.github.io/blog/2016/06/09/psql-graph/

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. If even someone need another format, she
can write a conversion script and add it to her macro. Thus, I wouldn't
like seeing this feature rejected without better alternative proposed.

Alternatively, we could introduce ability for single-line format change,
allowing to change psql output format options whose are set back to
original values after execution of current line.

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