Horton

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

Cat <cat@zip.com.au>

View thread
From: Cat <cat@zip.com.au>
To: Stephen Frost <sfrost@snowman.net>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, D'Arcy Cain <darcy@druid.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-01-28T22:20:01Z
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 Fri, Jan 27, 2017 at 11:03:05AM -0500, Stephen Frost wrote:
> Well, I did get the impression that you weren't thinking about that,
> which is actually kind of surpirsing to me.  Lots of things work on "the
> current query buffer", which is the last query (successful or not, to be
> clear..):
> 
> \crosstabview
> \e
> \g
> \gexec
> \gset
> \p
> \w
> \watch
> 
> It's not entirely clear to me why the docs sometimes say "current query
> buffer" and somtimes say "current query input buffer".

I would expect the "current query input buffer" to be what is used to
enter the next query. When you hit enter that goes into the "current query
buffer" (as the entered query is now officially complete and thus becomes
the current query) and then "current query input buffer" is cleared for
the next action to be dealt with, be it a query or psql command.

-- 
  "A search of his car uncovered pornography, a homemade sex aid, women's 
  stockings and a Jack Russell terrier."
    - http://www.dailytelegraph.com.au/news/wacky/indeed/story-e6frev20-1111118083480