Re: One-shot expanded output in psql using \G

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Christoph Berg <christoph.berg@credativ.de>, Daniel Verite <daniel@manitou-mail.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-01-30T13:46:08Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. psql: Fix \gx when FETCH_COUNT is used

  2. psql: Add \gx command

* Christoph Berg (christoph.berg@credativ.de) wrote:
> Re: Daniel Verite 2017-01-28 <74e7fd23-f5a9-488d-a8c4-1e0da674b27c@manitou-mail.org>
> > > Mysql's CLI client is using \G for this purpose, and adding the very
> > > same functionality to psql fits nicely into the set of existing
> > > backslash commands: \g sends the query buffer, \G will do exactly the
> > > same as \g (including parameters), but forces expanded output just for
> > > this query.
> > 
> > +1 for the functionality but should we choose to ignore the comparison
> > to mysql, I'd suggest \gx for the name.
> 
> IMHO \G is a tad easier to type than \gx, though the difference isn't
> huge, so I would be fine with either. But do we really want to choose
> something different just because MySQL is using it? \G will be much
> easier to explain to existing users (both people coming from MySQL to
> PostgreSQL, and PostgreSQL users doing a detour into foreign
> territory), and it would be one difference less to have to care about
> when typing on the CLIs.
> 
> +1 on \G.

Agreed, +1 on \G and with the above argument- why in the world would we
want to avoid using \G just because MySQL uses it?

Thanks!

Stephen