Re: One-shot expanded output in psql using \G
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: 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:49:17Z
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 →
-
psql: Fix \gx when FETCH_COUNT is used
- 0cdc3e47bea4 11.0 landed
- 51d0fa8ed93f 10.0 landed
-
psql: Add \gx command
- b2678efd43f1 10.0 landed
Stephen Frost <sfrost@snowman.net> writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> 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. > That's not how '\dx' works, as I pointed out, so I don't see having the > second character being 'x' to imply "\x mode" makes sense. It is how \d[tisv] works, or the S or + modifiers to \d. If you don't like the "x" in particular, feel free to propose a different letter that makes more sense to you --- but I'm pretty convinced that this ought to be seen as \g-plus-a-modifier. >> 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. > I don't believe there's any reason to think someone else couldn't come > along later and add \gq for whatever they want. Simply because we use > \G for something doesn't mean \g can't ever be further extended. So at some point we'd be documenting \G as a legacy mysql-compatible spelling of \gx, because it would become blindingly obvious that it was a non-orthogonal wart. Let's just skip that phase and get to the extensible syntax. regards, tom lane