Horton

Thread

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

  1. One-shot expanded output in psql using \G

    Christoph Berg <christoph.berg@credativ.de> — 2017-01-27T13:27:37Z

    I frequently find myself in the situation that I want the "\x"
expanded output mode activated just for one query. There's little
wrong with typing "\x" and re-executing the query in that case, but
then I'm always annoyed that the expanded output is still active for
the next query after that.

"\x auto" is not a fix for the problem; I have set up the pager to use
"less -S" (non-wrapping) by default so I can scroll right/left through
the query result instead of having it spread over several terminal
lines.

A workaround is to submit queries using "\x\g\x", but that's ugly,
clutters the output with toggle messages, and will forget that "\x
auto" was set.

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.

The same idea was discussed back in 2008. Back then the outcome was
that "\x auto" was implemented, but I still think that \G is a useful
feature to have on its own, and several people in the thread seem to
have agreed back then.

Patch attached, I'll add it to the next commit fest.

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

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

    Stephen Frost <sfrost@snowman.net> — 2017-01-27T13:52:54Z

    Christoph,

* Christoph Berg (christoph.berg@credativ.de) wrote:
> The same idea was discussed back in 2008. Back then the outcome was
> that "\x auto" was implemented, but I still think that \G is a useful
> feature to have on its own, and several people in the thread seem to
> have agreed back then.

+1 for my part.  I often run a query and then realize that I really
wanted \x output.

Thanks!

Stephen

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

    Christoph Berg <christoph.berg@credativ.de> — 2017-01-27T15:00:11Z

    Re: To PostgreSQL Hackers 2017-01-27 <20170127132737.6skslelaf4txs6iw@msg.credativ.de>
> The same idea was discussed back in 2008. Back then the outcome was
> that "\x auto" was implemented, but I still think that \G is a useful
> feature to have on its own, and several people in the thread seem to
> have agreed back then.

I forgot to add the archive URL here:
https://www.postgresql.org/message-id/758d5e7f0804030023j659d72e6nd66a9d6b93b30886%40mail.gmail.com

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

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

    David Fetter <david@fetter.org> — 2017-01-27T15:05:29Z

    On Fri, Jan 27, 2017 at 02:27:37PM +0100, Christoph Berg wrote:
> I frequently find myself in the situation that I want the "\x"
> expanded output mode activated just for one query. There's little
> wrong with typing "\x" and re-executing the query in that case, but
> then I'm always annoyed that the expanded output is still active for
> the next query after that.

+1

Your situation is familiar to me, and likely common among heavy users
of psql.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

    D'Arcy Cain <darcy@druid.net> — 2017-01-27T15:16:31Z

    On 2017-01-27 10:05 AM, David Fetter wrote:
> On Fri, Jan 27, 2017 at 02:27:37PM +0100, Christoph Berg wrote:
>> I frequently find myself in the situation that I want the "\x"
>> expanded output mode activated just for one query. There's little
>> wrong with typing "\x" and re-executing the query in that case, but
>> then I'm always annoyed that the expanded output is still active for
>> the next query after that.
>
> +1
>
> Your situation is familiar to me, and likely common among heavy users
> of psql.

I am a pretty heavy user of psql but I don't think that that would be so 
helpful.  I assume you mean a new option, let's call it "\X" the causes 
the next query to be expanded.  I type "\X" then a query.  I realize 
that I made a mistake and have to redo the query so I have to type "\X" 
again.  If I forget then I have to run the query yet again.

What would be useful for me is a control that causes every query to be 
expanded if it returns exactly one row.  Now I can do this:

SELECT * FROM table WHERE table_status = 1; % get a short list
SELECT * FROM table WHERE table_id = 123; % drill down to one ID

The first would give me a normal list and the second would give me an 
expanded look at the one I want to see in detail.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 788 2246     (DoD#0082)    (eNTP)   |  what's for dinner.
IM: darcy@Vex.Net, VoIP: sip:darcy@druid.net

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

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-01-27T15:26:09Z

    D'Arcy Cain wrote:

> I am a pretty heavy user of psql but I don't think that that would be so
> helpful.  I assume you mean a new option, let's call it "\X" the causes the
> next query to be expanded.  I type "\X" then a query.  I realize that I made
> a mistake and have to redo the query so I have to type "\X" again.  If I
> forget then I have to run the query yet again.

I think the suggestion is that \G replaces \g (which is the same thing
as the semicolon).  So you would do this:

SELECT * FROM table WHERE table_status = 1; % get a short list; normal output
SELECT * FROM table WHERE table_id = 123 \G % drill down to one ID

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

    Stephen Frost <sfrost@snowman.net> — 2017-01-27T15:31:16Z

    * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> D'Arcy Cain wrote:
> 
> > I am a pretty heavy user of psql but I don't think that that would be so
> > helpful.  I assume you mean a new option, let's call it "\X" the causes the
> > next query to be expanded.  I type "\X" then a query.  I realize that I made
> > a mistake and have to redo the query so I have to type "\X" again.  If I
> > forget then I have to run the query yet again.
> 
> I think the suggestion is that \G replaces \g (which is the same thing
> as the semicolon).  So you would do this:
> 
> SELECT * FROM table WHERE table_status = 1; % get a short list; normal output
> SELECT * FROM table WHERE table_id = 123 \G % drill down to one ID

Uh, I figured it was more like \g, which just re-runs the last query..
As in, you'd do:

table pg_proc; % blargh, I can't read it like this
\G % ahh, much nicer

Thanks!

Stephen

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

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-01-27T15:42:31Z

    Stephen Frost wrote:
> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

> > I think the suggestion is that \G replaces \g (which is the same thing
> > as the semicolon).  So you would do this:
> > 
> > SELECT * FROM table WHERE table_status = 1; % get a short list; normal output
> > SELECT * FROM table WHERE table_id = 123 \G % drill down to one ID
> 
> Uh, I figured it was more like \g, which just re-runs the last query..
> As in, you'd do:
> 
> table pg_proc; % blargh, I can't read it like this
> \G % ahh, much nicer

Sure, that's exactly the same thing.  (You can omit the query in either
case which causes the previous query to be re-ran.  \crosstabview,
\gexec etc also work like that).

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

    David G. Johnston <david.g.johnston@gmail.com> — 2017-01-27T15:46:56Z

    On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost <sfrost@snowman.net> wrote:

> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > D'Arcy Cain wrote:
> >
> > > I am a pretty heavy user of psql but I don't think that that would be
> so
> > > helpful.  I assume you mean a new option, let's call it "\X" the
> causes the
> > > next query to be expanded.  I type "\X" then a query.  I realize that
> I made
> > > a mistake and have to redo the query so I have to type "\X" again.  If
> I
> > > forget then I have to run the query yet again.
> >
> > I think the suggestion is that \G replaces \g (which is the same thing
> > as the semicolon).  So you would do this:
> >
> > SELECT * FROM table WHERE table_status = 1; % get a short list; normal
> output
> > SELECT * FROM table WHERE table_id = 123 \G % drill down to one ID
>
> Uh, I figured it was more like \g, which just re-runs the last query..
> As in, you'd do:
>
> table pg_proc; % blargh, I can't read it like this
> \G % ahh, much nicer
>

​This information surprised me.  It was unexpected that the last
successfully executed query remains in the query buffer until the next SQL
(and not meta) command is started.  I was expecting that as soon as result
was returned to the screen the current query buffer would be cleared in
preparation for the next query.​

A sentence or two describing this behavior (or, more generally the query
buffer itself), probably placed at the end of the "Entering SQL Commands"
section, would help to make this common knowledge.

David J.

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

    Stephen Frost <sfrost@snowman.net> — 2017-01-27T16:03:05Z

    * David G. Johnston (david.g.johnston@gmail.com) wrote:
> On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost <sfrost@snowman.net> wrote:
> 
> > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > > D'Arcy Cain wrote:
> > >
> > > > I am a pretty heavy user of psql but I don't think that that would be
> > so
> > > > helpful.  I assume you mean a new option, let's call it "\X" the
> > causes the
> > > > next query to be expanded.  I type "\X" then a query.  I realize that
> > I made
> > > > a mistake and have to redo the query so I have to type "\X" again.  If
> > I
> > > > forget then I have to run the query yet again.
> > >
> > > I think the suggestion is that \G replaces \g (which is the same thing
> > > as the semicolon).  So you would do this:
> > >
> > > SELECT * FROM table WHERE table_status = 1; % get a short list; normal
> > output
> > > SELECT * FROM table WHERE table_id = 123 \G % drill down to one ID
> >
> > Uh, I figured it was more like \g, which just re-runs the last query..
> > As in, you'd do:
> >
> > table pg_proc; % blargh, I can't read it like this
> > \G % ahh, much nicer
> >
> 
> This information surprised me.  It was unexpected that the last
> successfully executed query remains in the query buffer until the next SQL
> (and not meta) command is started.  I was expecting that as soon as result
> was returned to the screen the current query buffer would be cleared in
> preparation for the next query.

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".

> A sentence or two describing this behavior (or, more generally the query
> buffer itself), probably placed at the end of the "Entering SQL Commands"
> section, would help to make this common knowledge.

Generally speaking, I agree that we should be more consistent in the
docs, use one term where we mean one thing, and define that term
somewhere.

Thanks!

Stephen

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

    Stephen Frost <sfrost@snowman.net> — 2017-01-27T16:05:44Z

    * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> 
> > > I think the suggestion is that \G replaces \g (which is the same thing
> > > as the semicolon).  So you would do this:
> > > 
> > > SELECT * FROM table WHERE table_status = 1; % get a short list; normal output
> > > SELECT * FROM table WHERE table_id = 123 \G % drill down to one ID
> > 
> > Uh, I figured it was more like \g, which just re-runs the last query..
> > As in, you'd do:
> > 
> > table pg_proc; % blargh, I can't read it like this
> > \G % ahh, much nicer
> 
> Sure, that's exactly the same thing.  (You can omit the query in either
> case which causes the previous query to be re-ran.  \crosstabview,
> \gexec etc also work like that).

Right, I agree it's the same thing, but (clearly), not everyone
discussing this realized that and, well, the \G-by-itself is a lot
easier for me, at least.  I have a really hard time not ending things
with a semi-colon. ;)

Thanks!;

Stephen;

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

    Christoph Berg <christoph.berg@credativ.de> — 2017-01-27T18:05:51Z

    Re: Stephen Frost 2017-01-27 <20170127160544.GI9812@tamriel.snowman.net>
> > > Uh, I figured it was more like \g, which just re-runs the last query..
> > > As in, you'd do:
> > > 
> > > table pg_proc; % blargh, I can't read it like this
> > > \G % ahh, much nicer
> > 
> > Sure, that's exactly the same thing.  (You can omit the query in either
> > case which causes the previous query to be re-ran.  \crosstabview,
> > \gexec etc also work like that).
> 
> Right, I agree it's the same thing, but (clearly), not everyone
> discussing this realized that and, well, the \G-by-itself is a lot
> easier for me, at least.  I have a really hard time not ending things
> with a semi-colon. ;)

Heh, tbh even I as the patch other didn't realize that \G-by-itself
just works, my intention was that it replaces the semicolon. :)

So, to clarify, both ways work:

select * from pg_class where relname = 'pg_class';
-- dang, much too wide, press <arrow-up>
select * from pg_class where relname = 'pg_class' \G
-- ah nice!

select * from pg_class where relname = 'pg_class';
-- dang, much too wide
\G
-- ah nice!

Christoph

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

    Daniel Verite <daniel@manitou-mail.org> — 2017-01-28T17:42:49Z

    	Christoph Berg wrote:

> A workaround is to submit queries using "\x\g\x", but that's ugly,
> clutters the output with toggle messages, and will forget that "\x
> auto" was set.
> 
> 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.


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

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

    Cat <cat@zip.com.au> — 2017-01-28T22:20:01Z

    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

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

    Christoph Berg <christoph.berg@credativ.de> — 2017-01-30T10:14:25Z

    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.

Christoph

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

    Stephen Frost <sfrost@snowman.net> — 2017-01-30T13:46:08Z

    * 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

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

    Pavel Stehule <pavel.stehule@gmail.com> — 2017-01-30T14:40:39Z

    2017-01-30 14:46 GMT+01:00 Stephen Frost <sfrost@snowman.net>:

> * 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?
>

The argument so MySQL uses it is not good. But \gx respect convention and
it is little bit more descriptive.

The difference is minor - I prefer \gx due consistency with Postgres. I
don't know much MySQL people who use a terminal.

Regards

Pavel



>
> Thanks!
>
> Stephen
>

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

    Daniel Verite <daniel@manitou-mail.org> — 2017-01-30T14:45:41Z

    	Christoph Berg wrote:

> But do we really want to choose
> something different just because MySQL is using it?

That's not what I meant. If mysql wasn't using \G
I'd still suggest the name \gx because:

- it means the functionality of \g combined with \x so
semantically it makes sense.

- there is no precedent in psql that the upper-case version
of a meta-command as a variant of the lower-case version:
\C has nothing to do with \c, and \H nothing with \h, and
\T and \t are equally disconnected

- there hasn't been much use up to now of uppercase
meta-commands, C,T and H are the only ones I see in \?
\d[something] is crowded  with lots of "something", whereas \D is not
used at all. The pattern seems to be that uppercase is the exception.

FWIW I don't share the feeling that \G is easier to remember or type
than \gx.

> \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.

That's a good argument, but if it's pitted against psql's
consistency with itself, I'd expect the latter to win.

Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-30T15:00:02Z

    "Daniel Verite" <daniel@manitou-mail.org> writes:
>> \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.

> That's a good argument, but if it's pitted against psql's
> consistency with itself, I'd expect the latter to win.

FWIW, \gx makes sense to me as well, particularly if we make it a
complete extension of \g and allow an optional target file name.
Does that functionality exist in mysql's \G ?

			regards, tom lane

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

    Stephen Frost <sfrost@snowman.net> — 2017-01-30T15:04:59Z

    * Pavel Stehule (pavel.stehule@gmail.com) wrote:
> 2017-01-30 14:46 GMT+01:00 Stephen Frost <sfrost@snowman.net>:
> 
> > * 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?
> >
> 
> The argument so MySQL uses it is not good. But \gx respect convention and
> it is little bit more descriptive.
> 
> The difference is minor - I prefer \gx due consistency with Postgres. I
> don't know much MySQL people who use a terminal.

This particular bike-shedding really doesn't seem to be terribly useful
or sensible, to me.  \gx isn't "consistent" or "descriptive", frankly.

If anything, 'x' as the second character, today, implies "extension" as
it's used that way by \dx.

Let's go with \G and be done with it.

Thanks!

Stephen

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-30T15:14:36Z

    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.

			regards, tom lane

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

    Christoph Berg <christoph.berg@credativ.de> — 2017-01-30T15:18:05Z

    Re: Tom Lane 2017-01-30 <23622.1485788402@sss.pgh.pa.us>
> FWIW, \gx makes sense to me as well, particularly if we make it a
> complete extension of \g and allow an optional target file name.
> Does that functionality exist in mysql's \G ?

MySQL's (5.5 here) \G does not support a filename argument. (It will
instead stuff the argument into the next query buffer.)

(The \G patch already supports the filename argument.)

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

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

    David G. Johnston <david.g.johnston@gmail.com> — 2017-01-30T15:22:40Z

    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
​

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

    Stephen Frost <sfrost@snowman.net> — 2017-01-30T15:35:33Z

    Tom,

* 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.

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.

Further, as it relates to formatting, "\x mode" is, far and away in my
experience, the only regularly used alternative formatting in
interactive psql sessions.

I can't recall ever using the other formatting toggles (aligned, HTML,
and tuples only) before in interactive sessions, except (rarely) with
\o.  I tend to think we've got them primairly to provide the same
options that we have at the command-line, which can be handy, but not
because I'm very often going to want to flip between aligned and
unaligned mode while querying tables.

> 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.

> 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.

I agree that we don't currently have a case that upper case means a
variant of a lower case command, but I'm not arguing that we do.

We do have cases where various \d sub-commands end up being very
different things depending on if it's a lower-case letter or an
upper-case letter, but that doesn't imply, to me at least, that every
use of an upper-case letter must be completely different from what the
lower-case letter is for.

Obviously, I'd like to have this and if enough people think that the
right answer is '\gx', then so be it, but I don't buy the consistency
argument and without actual consistency across commands which take 'x'
as a sub-command I don't see the 'descriptive' argument as holding much
weight either.

Thanks!

Stephen

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-30T15:49:17Z

    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

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

    David G. Johnston <david.g.johnston@gmail.com> — 2017-01-30T15:52:36Z

    On Mon, Jan 30, 2017 at 8:35 AM, Stephen Frost <sfrost@snowman.net> wrote:

> Tom,
>
> * 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.
>
> 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 makes perfect sense ... it just not something that we've had the option
to do before (no, I haven't tried to figure out if we've missed an
opportunity or two here).​

​[...]​

without actual consistency across commands which take 'x'
> as a sub-command I don't see the 'descriptive' argument as holding much
> weight either
> ​.
>

​Arguing that something is mnemonic doesn't require any precedence - though
one could wish for better uses of mnemonic naming choices for past and
future items.

In scripting uses of psql I could see wanting to use "\gx" and, say "\gn"
(i.e., always output in non-expanded mode) instead of ";" so that for any
given query I can specify the exact layout I care about and don't have to
jump through hoops to toggle \x back and forth.

Limiting consideration of the use-case of this feature to interactive use
is, IMHO, a mistake.  In the copious use of psql scripting that I do I
would find both options I named above to be useful to directly and
concisely communicate the display intent of each query I execute.

David J.

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

    Stephen Frost <sfrost@snowman.net> — 2017-01-30T16:06:03Z

    David,

* David G. Johnston (david.g.johnston@gmail.com) wrote:
> On Mon, Jan 30, 2017 at 8:35 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > * 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.
> >
> > 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 makes perfect sense ... it just not something that we've had the option
> to do before (no, I haven't tried to figure out if we've missed an
> opportunity or two here).

For my 2c, at least, I think we have..  I could certainly see it as very
useful to have expanded output for \d and various \d sub-commands.  How
are we going to get there today?  I don't see us re-defining what \dx
means. 

With this, what we could do is define \D to be the same as \d but in
expanded mode.  For something like \dp, having a \Dp option could be
pretty nice.

> > without actual consistency across commands which take 'x'
> > as a sub-command I don't see the 'descriptive' argument as holding much
> > weight either
> > ​.
> 
> Arguing that something is mnemonic doesn't require any precedence - though
> one could wish for better uses of mnemonic naming choices for past and
> future items.

I can see the mnemonic argument, just not one based on some kind of
consistency with what we've actually got implemented today.

> In scripting uses of psql I could see wanting to use "\gx" and, say "\gn"
> (i.e., always output in non-expanded mode) instead of ";" so that for any
> given query I can specify the exact layout I care about and don't have to
> jump through hoops to toggle \x back and forth.

Ugh.  I would *much* rather scripting be clear and set things up ahead
of time instead of changing a would-be query-ending ';' into a backslash
command to indicate the output format for the prior query.

> Limiting consideration of the use-case of this feature to interactive use
> is, IMHO, a mistake.  In the copious use of psql scripting that I do I
> would find both options I named above to be useful to directly and
> concisely communicate the display intent of each query I execute.

I'm afraid we might just have to disagree on our preferences for script
writing then.  In any case, as I said up-thread, using \G for this
doesn't mean we couldn't make other \g options if people have a use-case
for them.

Thanks!

Stephen

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

    David Fetter <david@fetter.org> — 2017-01-30T17:08:36Z

    On Mon, Jan 30, 2017 at 08:22:40AM -0700, David G. Johnston wrote:
> 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

+1 from me, too, for what it's worth.

If we're expanding the meanings of \g, let's do it with at least some
eye to future expansions.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

    Daniel Verite <daniel@manitou-mail.org> — 2017-01-31T12:21:49Z

    	Stephen Frost wrote:

> 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.

\gx means "like \g but output with expanded display"
It turns out that it's semantically close to "\g with \x" so
I refered to it like that as a shortcut upthread, my fault.
It was never meant to establish a precedent that combining
two letters would mean "do the first one-letter command and the
second as a sub-command" which indeed woud be inconsistent with
the existing \ef, \sf, \sv, \d[*] and so on.

> I can't recall ever using the other formatting toggles (aligned, HTML,
> and tuples only) before in interactive sessions, except (rarely) with
> \o.

\a is handy to read sizeable chunks of text in fields that 
contain newlines, and personally I need it on a regular basis
in interactive sessions. It depends on the kind of data you have to work
with.


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

  30. Re: One-shot expanded output in psql using \gx

    Christoph Berg <christoph.berg@credativ.de> — 2017-02-06T19:54:13Z

    The majority of voices here was in favor of using \gx, so here is
another version of the same patch which implements that.

Christoph

  31. Re: One-shot expanded output in psql using \gx

    David Fetter <david@fetter.org> — 2017-02-07T05:16:59Z

    On Mon, Feb 06, 2017 at 08:54:13PM +0100, Christoph Berg wrote:
> The majority of voices here was in favor of using \gx, so here is
> another version of the same patch which implements that.

Patch is useful, and works as documented.

Maybe it could get a test or two in src/test/regress/*/psql.*

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

  32. Re: One-shot expanded output in psql using \gx

    Christoph Berg <christoph.berg@credativ.de> — 2017-02-08T14:52:40Z

    Re: David Fetter 2017-02-07 <20170207051659.GC3552@fetter.org>
> On Mon, Feb 06, 2017 at 08:54:13PM +0100, Christoph Berg wrote:
> > The majority of voices here was in favor of using \gx, so here is
> > another version of the same patch which implements that.
> 
> Patch is useful, and works as documented.
> 
> Maybe it could get a test or two in src/test/regress/*/psql.*

Good point. The new version tests \g and \gx with a new query, and
re-running it on the last query buffer.

Christoph
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

  33. Re: One-shot expanded output in psql using \gx

    David Fetter <david@fetter.org> — 2017-02-08T15:12:14Z

    On Wed, Feb 08, 2017 at 03:52:40PM +0100, Christoph Berg wrote:
> Re: David Fetter 2017-02-07 <20170207051659.GC3552@fetter.org>
> > On Mon, Feb 06, 2017 at 08:54:13PM +0100, Christoph Berg wrote:
> > > The majority of voices here was in favor of using \gx, so here is
> > > another version of the same patch which implements that.
> > 
> > Patch is useful, and works as documented.
> > 
> > Maybe it could get a test or two in src/test/regress/*/psql.*
> 
> Good point. The new version tests \g and \gx with a new query, and
> re-running it on the last query buffer.
>   
> ! 	/* \g [filename] -- send query, optionally with output to file/pipe */
> ! 	else if (strcmp(cmd, "g") == 0)
>   	{
>   		char	   *fname = psql_scan_slash_option(scan_state,
>   												   OT_FILEPIPE, NULL, false);
> --- 910,920 ----
>   		free(fname);
>   	}
>   
> ! 	/*
> ! 	 * \g [filename] -- send query, optionally with output to file/pipe
> ! 	 * \gx [filename] -- same as \g, with expanded mode forced
> ! 	 */
> ! 	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0)
>   	{
>   		char	   *fname = psql_scan_slash_option(scan_state,
>   												   OT_FILEPIPE, NULL, false);
> *************** exec_command(const char *cmd,
> *** 924,929 ****
> --- 927,934 ----
>   			pset.gfname = pg_strdup(fname);
>   		}
>   		free(fname);
> + 		if (strcmp(cmd, "gx") == 0)
> + 			pset.g_expanded = true;
>   		status = PSQL_CMD_SEND;
>   	}

Would you be open to saving the next person some work by doing
something similar to how \d is done, namely looking for an 'x'
modifier after g without regard to how far after?  As of this writing,
the \d version starts at line 398 in master.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

  34. Re: One-shot expanded output in psql using \gx

    Christoph Berg <christoph.berg@credativ.de> — 2017-02-09T10:12:00Z

    Re: David Fetter 2017-02-08 <20170208151214.GA8118@fetter.org>
> Would you be open to saving the next person some work by doing
> something similar to how \d is done, namely looking for an 'x'
> modifier after g without regard to how far after?  As of this writing,
> the \d version starts at line 398 in master.

I think that ship has sailed, given there's already \gset.
Supporting \g[optionset] next to it *now*, given no one knows how
"optionset" is going to evolve seems like premature optimization.

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

  35. Re: One-shot expanded output in psql using \gx

    David Fetter <david@fetter.org> — 2017-02-09T14:48:25Z

    On Thu, Feb 09, 2017 at 11:12:00AM +0100, Christoph Berg wrote:
> Re: David Fetter 2017-02-08 <20170208151214.GA8118@fetter.org>
> > Would you be open to saving the next person some work by doing
> > something similar to how \d is done, namely looking for an 'x'
> > modifier after g without regard to how far after?  As of this writing,
> > the \d version starts at line 398 in master.
> 
> I think that ship has sailed, given there's already \gset.
> Supporting \g[optionset] next to it *now*, given no one knows how
> "optionset" is going to evolve seems like premature optimization.

Good point.  Thanks for looking it over.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

  36. Re: One-shot expanded output in psql using \gx

    Daniel Verite <daniel@manitou-mail.org> — 2017-03-03T19:11:49Z

    	Christoph Berg wrote:

> The new version tests \g and \gx with a new query, and
> re-running it on the last query buffer.

Thanks, here's a review:

The patch compiles and works as expected.

The code follows the same pattern as other one-shot command
modifiers, setting a flag in the global "pset" struct
in exec_command() and resetting it at the end of SendQuery().

- make installcheck-world: ok

- sgml doc: ok

- help text: ok

- includes regression tests: ok

- tab-completion: works but the list in tab-complete.c:backslash_commands[]
is sorted alphabetically so "\\gx" should come after "\\gset"

- another nitpick: in PrintQueryTuples() it assigns a bool:
+	/* one-shot expanded output requested via \gx */
+	if (pset.g_expanded)
+		my_popt.topt.expanded = true;
+ 

"expanded" is defined as a tri-valued short int (print.h:98):
  typedef struct printTableOpt
  {
    //....
    unsigned short int expanded;    /* expanded/vertical output (if supported
by
				     * output format); 0=no, 1=yes, 2=auto */
Although there is still code that puts true/false in this variable
(probably because it was a bool before?), I assume that for new
code, assigning 0/1/2 should be preferred.


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

  37. Re: One-shot expanded output in psql using \gx

    Christoph Berg <christoph.berg@credativ.de> — 2017-03-06T12:42:33Z

    Re: Daniel Verite 2017-03-03 <4d84079e-325b-48c5-83e6-bb54bb567bb1@manitou-mail.org>
> - tab-completion: works but the list in tab-complete.c:backslash_commands[]
> is sorted alphabetically so "\\gx" should come after "\\gset"

Good catch, it was still in that place from when it was named \G.

In the \? output I left it directly after \g because the help text
starts with "as \g ..." and it is IMHO more closely related to \g than
\gexec and \gset which differ more in functionality.

>     unsigned short int expanded;    /* expanded/vertical output (if supported
> by
> 				     * output format); 0=no, 1=yes, 2=auto */
> Although there is still code that puts true/false in this variable
> (probably because it was a bool before?), I assume that for new
> code, assigning 0/1/2 should be preferred.

Right. I had seen both being used and went with "true", but "1" is
better style.

Both fixed, thanks for the review! Version 3 attached.

Christoph
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

  38. Re: One-shot expanded output in psql using \gx

    Daniel Verite <daniel@manitou-mail.org> — 2017-03-07T12:55:30Z

    	Christoph Berg wrote:

> Both fixed, thanks for the review! Version 3 attached.

It looks good to me.

Stephen Frost is also reviewer on the patch, so I'm moving the
status back to "Needs review" at
https://commitfest.postgresql.org/13/973/
and let him proceed.


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

  39. Re: One-shot expanded output in psql using \gx

    Stephen Frost <sfrost@snowman.net> — 2017-03-07T13:15:41Z

    * Daniel Verite (daniel@manitou-mail.org) wrote:
> 	Christoph Berg wrote:
> 
> > Both fixed, thanks for the review! Version 3 attached.
> 
> It looks good to me.
> 
> Stephen Frost is also reviewer on the patch, so I'm moving the
> status back to "Needs review" at
> https://commitfest.postgresql.org/13/973/
> and let him proceed.

Right, starting to look at it now.

Thanks!

Stephen

  40. Re: One-shot expanded output in psql using \gx

    Tobias Bussmann <t.bussmann@gmx.net> — 2017-08-15T20:24:34Z

    I've tested the new \gx against 10beta and current git HEAD. Actually one of my favourite features of PostgreSQL 10! However in my environment it was behaving strangely. After some debugging I found that \gx does not work if you have \set FETCH_COUNT n before. Please find attached a patch that fixes this incl. new regression test.

Best regards,
Tobias

  41. Re: One-shot expanded output in psql using \gx

    Noah Misch <noah@leadboat.com> — 2017-08-17T02:24:41Z

    On Tue, Aug 15, 2017 at 10:24:34PM +0200, Tobias Bussmann wrote:
> I've tested the new \gx against 10beta and current git HEAD. Actually one of my favourite features of PostgreSQL 10! However in my environment it was behaving strangely. After some debugging I found that \gx does not work if you have \set FETCH_COUNT n before. Please find attached a patch that fixes this incl. new regression test.

[Action required within three days.  This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item.  Stephen,
since you committed the patch believed to have created it, you own this open
item.  If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know.  Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message.  Include a date for your subsequent status update.  Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10.  Consequently, I will appreciate your efforts
toward speedy resolution.  Thanks.

[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

  42. Re: One-shot expanded output in psql using \gx

    Stephen Frost <sfrost@snowman.net> — 2017-08-17T02:33:51Z

    Noah, all,

On Wed, Aug 16, 2017 at 22:24 Noah Misch <noah@leadboat.com> wrote:

> On Tue, Aug 15, 2017 at 10:24:34PM +0200, Tobias Bussmann wrote:
> > I've tested the new \gx against 10beta and current git HEAD. Actually
> one of my favourite features of PostgreSQL 10! However in my environment it
> was behaving strangely. After some debugging I found that \gx does not work
> if you have \set FETCH_COUNT n before. Please find attached a patch that
> fixes this incl. new regression test.
>
> [Action required within three days.  This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 10 open item.  Stephen,
> since you committed the patch believed to have created it, you own this
> open
> item.  If some other commit is more relevant or if this does not belong as
> a
> v10 open item, please let us know.  Otherwise, please observe the policy on
> open item ownership[1] and send a status update within three calendar days
> of
> this message.  Include a date for your subsequent status update.  Testers
> may
> discover new open items at any time, and I want to plan to get them all
> fixed
> well in advance of shipping v10.  Consequently, I will appreciate your
> efforts
> toward speedy resolution.  Thanks.


I'm in Boston this week but should be able to address this no later than
Monday, August 21st,  and I will provide an update then.

Thanks!

Stephen

  43. Re: One-shot expanded output in psql using \gx

    Stephen Frost <sfrost@snowman.net> — 2017-08-19T17:23:45Z

    Noah, all,

* Noah Misch (noah@leadboat.com) wrote:
> On Tue, Aug 15, 2017 at 10:24:34PM +0200, Tobias Bussmann wrote:
> > I've tested the new \gx against 10beta and current git HEAD. Actually one of my favourite features of PostgreSQL 10! However in my environment it was behaving strangely. After some debugging I found that \gx does not work if you have \set FETCH_COUNT n before. Please find attached a patch that fixes this incl. new regression test.
> 
> [Action required within three days.  This is a generic notification.]

I'll address this on Tuesday, 8/22.

Thanks!

Stephen

  44. Re: One-shot expanded output in psql using \gx

    Stephen Frost <sfrost@snowman.net> — 2017-08-24T00:45:58Z

    * Noah Misch (noah@leadboat.com) wrote:
> On Tue, Aug 15, 2017 at 10:24:34PM +0200, Tobias Bussmann wrote:
> > I've tested the new \gx against 10beta and current git HEAD. Actually one of my favourite features of PostgreSQL 10! However in my environment it was behaving strangely. After some debugging I found that \gx does not work if you have \set FETCH_COUNT n before. Please find attached a patch that fixes this incl. new regression test.
> 
> [Action required within three days.  This is a generic notification.]
> 
> The above-described topic is currently a PostgreSQL 10 open item.  Stephen,
> since you committed the patch believed to have created it, you own this open
> item.  If some other commit is more relevant or if this does not belong as a
> v10 open item, please let us know.  Otherwise, please observe the policy on
> open item ownership[1] and send a status update within three calendar days of
> this message.  Include a date for your subsequent status update.  Testers may
> discover new open items at any time, and I want to plan to get them all fixed
> well in advance of shipping v10.  Consequently, I will appreciate your efforts
> toward speedy resolution.  Thanks.

Just to preempt the coming nagging email, yes, I'm aware I didn't get to
finish this today (though at least today, unlike yesterday, I looked at
it and started to play with it..  I blame the celestial bodies that
caused an impressive traffic jam on Monday night causing me to lose
basically all of Tuesday too..).

I'll provide an update tomorrow.

Thanks!

Stephen

  45. Re: One-shot expanded output in psql using \gx

    Stephen Frost <sfrost@snowman.net> — 2017-08-24T20:22:23Z

    * Noah Misch (noah@leadboat.com) wrote:
> On Tue, Aug 15, 2017 at 10:24:34PM +0200, Tobias Bussmann wrote:
> > I've tested the new \gx against 10beta and current git HEAD. Actually one of my favourite features of PostgreSQL 10! However in my environment it was behaving strangely. After some debugging I found that \gx does not work if you have \set FETCH_COUNT n before. Please find attached a patch that fixes this incl. new regression test.

Fixed in 0cdc3e4.

Thanks for the report!

Stephen