Horton

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

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Pavel Stehule <pavel.stehule@gmail.com>, Christoph Berg <christoph.berg@credativ.de>, Daniel Verite <daniel@manitou-mail.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-01-30T15:22:40Z
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

On Mon, Jan 30, 2017 at 8:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Stephen Frost <sfrost@snowman.net> writes:
> > This particular bike-shedding really doesn't seem to be terribly useful
> > or sensible, to me.  \gx isn't "consistent" or "descriptive", frankly.
>
> Why not?  To me it reads as "\g with an x option".  The "x" refers to
> the implied "\x", so it's not an arbitrary choice at all.
>
> The main problem I see with \G is that it's a dead end.  If somebody
> comes along next year and says "I'd like a variant of \g with some other
> frammish", what will we do?  There are no more case variants to use.
>
> In short, really the direction this ought to go in is \g[options] [file]
> which is perfectly consistent with precedents in psql such as \d.
> But there isn't any place where we've decided that upper case means
> a variant of a lower case command.
>

​+1
​