Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cXbNW-0000ws-R7 for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Jan 2017 22:21:50 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cXbNW-0004w1-ES for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Jan 2017 22:21:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cXbM6-00023J-3L for pgsql-hackers@postgresql.org; Sat, 28 Jan 2017 22:20:22 +0000 Received: from nskntmtas06p.mx.bigpond.com ([61.9.168.152]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cXbLz-0002Vs-Jt for pgsql-hackers@postgresql.org; Sat, 28 Jan 2017 22:20:19 +0000 Received: from nskntcmgw07p ([61.9.169.167]) by nskntmtas06p.mx.bigpond.com with ESMTP id <20170128222006.BARC28818.nskntmtas06p.mx.bigpond.com@nskntcmgw07p>; Sat, 28 Jan 2017 22:20:06 +0000 Received: from bunyip.billabong.weebeastie.net ([121.209.109.122]) by nskntcmgw07p with BigPond Outbound id dyL51u0072eVLPM01yL5NA; Sat, 28 Jan 2017 22:20:06 +0000 X-Authority-Analysis: v=2.1 cv=CMfXJkfD c=1 sm=1 tr=0 a=R1vMt6NKEWqz1Wh5BvvVYg==:117 a=R1vMt6NKEWqz1Wh5BvvVYg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=IgFoBzBjUZAA:10 a=z4P2pbfkAAAA:8 a=f8EQk_d25mcykZwduZYA:9 a=CjuIK1q_8ugA:10 a=iOD0r4dPuSk-6nLGK4P5:22 Received: from hogarth by bunyip.billabong.weebeastie.net with local (Exim 4.88) (envelope-from ) id 1cXbLl-0004M6-NM; Sun, 29 Jan 2017 09:20:01 +1100 Date: Sun, 29 Jan 2017 09:20:01 +1100 From: Cat To: Stephen Frost Cc: "David G. Johnston" , Alvaro Herrera , D'Arcy Cain , "pgsql-hackers@postgresql.org" Subject: Re: One-shot expanded output in psql using \G Message-ID: <20170128222000.mnliffc3pwebz63j@zip.com.au> References: <8b8068d9-b218-06c6-6b98-8d7f1a365449@druid.net> <20170127152609.hsjdr5cetlxm47ke@alvherre.pgsql> <20170127153116.GF9812@tamriel.snowman.net> <20170127160305.GH9812@tamriel.snowman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170127160305.GH9812@tamriel.snowman.net> User-Agent: NeoMutt/20161126 (1.7.1) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers