Re: [HACKERS] One-shot expanded output in psql using \G - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] One-shot expanded output in psql using \G
Date
Msg-id 20170130134608.GA9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] One-shot expanded output in psql using \G  (Christoph Berg <christoph.berg@credativ.de>)
Responses Re: [HACKERS] One-shot expanded output in psql using \G  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
* 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

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Superowners
Next
From: Pavan Deolasee
Date:
Subject: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY