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

[Daniel Verite]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[David Fetter]

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  wrote:
> > Stephen Frost  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  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Stephen Frost]

David,

* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Mon, Jan 30, 2017 at 8:35 AM, Stephen Frost  wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > Stephen Frost  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


signature.asc
Description: Digital signature

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

[David G. Johnston]

On Mon, Jan 30, 2017 at 8:35 AM, Stephen Frost  wrote:

> Tom,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost  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.

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

[Tom Lane]

Stephen Frost  writes:
> * Tom Lane (t...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[David G. Johnston]

On Mon, Jan 30, 2017 at 8:14 AM, Tom Lane  wrote:

> Stephen Frost  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
​

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

[Stephen Frost]

Tom,

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost  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


signature.asc
Description: Digital signature

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

[Christoph Berg]

Re: Tom Lane 2017-01-30 <23622.1485788...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tom Lane]

Stephen Frost  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Stephen Frost]

* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2017-01-30 14:46 GMT+01:00 Stephen Frost :
> 
> > * Christoph Berg (christoph.b...@credativ.de) wrote:
> > > Re: Daniel Verite 2017-01-28 <74e7fd23-f5a9-488d-a8c4-
> > 1e0da674b...@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


signature.asc
Description: Digital signature

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

[Tom Lane]

"Daniel Verite"  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Daniel Verite]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Pavel Stehule]

2017-01-30 14:46 GMT+01:00 Stephen Frost :

> * Christoph Berg (christoph.b...@credativ.de) wrote:
> > Re: Daniel Verite 2017-01-28 <74e7fd23-f5a9-488d-a8c4-
> 1e0da674b...@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
>

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

[Stephen Frost]

* Christoph Berg (christoph.b...@credativ.de) wrote:
> Re: Daniel Verite 2017-01-28 
> <74e7fd23-f5a9-488d-a8c4-1e0da674b...@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


signature.asc
Description: Digital signature

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

[Christoph Berg]

Re: Daniel Verite 2017-01-28 
<74e7fd23-f5a9-488d-a8c4-1e0da674b...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Cat]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Daniel Verite]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Christoph Berg]

Re: Stephen Frost 2017-01-27 <20170127160544.gi9...@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 
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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Stephen Frost]

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@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;


signature.asc
Description: Digital signature

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

[Stephen Frost]

* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost  wrote:
> 
> > * Alvaro Herrera (alvhe...@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


signature.asc
Description: Digital signature

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

[David G. Johnston]

On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost  wrote:

> * Alvaro Herrera (alvhe...@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.

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

[Alvaro Herrera]

Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@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 Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Stephen Frost]

* Alvaro Herrera (alvhe...@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


signature.asc
Description: Digital signature

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

[Alvaro Herrera]

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 Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[D'Arcy Cain]

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  |  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: da...@vex.net, VoIP: sip:da...@druid.net


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[David Fetter]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Christoph Berg]

Re: To PostgreSQL Hackers 2017-01-27 
<20170127132737.6skslelaf4txs...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Stephen Frost]

Christoph,

* Christoph Berg (christoph.b...@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


signature.asc
Description: Digital signature

[HACKERS] One-shot expanded output in psql using \G

[Christoph Berg]

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
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
new file mode 100644
index 640fe12..af85888
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
*** Tue Oct 26 21:40:57 CEST 1999
*** 1891,1896 
--- 1891,1908 
  
  

+ \G [ filename ]
+ \G [ |command ]
+ 
+ 
+ \G is equivalent to \g, but
+ forces expanded output mode for this query.
+ 
+ 
+   
+ 
+ 
+   
  \gexec
  
  
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
new file mode 100644
index 0c164a3..912f672
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*** exec_command(const char *cmd,
*** 904,911 
  		free(fname);
  	}
  
! 	/* \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);
--- 904,914 
  		free(fname);
  	}
  
! 	/*
! 	 * \g [filename] -- send query, optionally with output to file/pipe
! 	 * \G [filename] -- same as \g, with expanded mode forced
! 	 */
! 	else if (strcasecmp(cmd, "g") == 0)
  	{
  		char	   *fname = psql_scan_slash_option(scan_state,
     OT_FILEPIPE, NULL, false);
*** exec_command(const char *cmd,
*** 918,923 
--- 921,928 
  			pset.gfname = pg_strdup(fname);
  		}
  		free(fname);
+ 		if (strcmp(cmd, "G") == 0)
+ 			pset.g_expanded = true;
  		status = PSQL_CMD_SEND;
  	}
  
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
new file mode 100644
index e1b04de..4a75470
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
*** PrintQueryTuples(const PGresult *results
*** 770,775 
--- 770,779 
  {
  	printQueryOpt my_popt = pset.popt;
  
+ 	/* one-shot expanded output requested via \G */
+ 	if (pset.g_expanded)
+ 		my_popt.topt.expanded = true;
+ 
  	/* write output to \g argument, if any */
  	if (pset.gfname)
  	{
*** sendquery_cleanup:
*** 1411,1416 
--- 1415,1423 
  		pset.gfname = NULL;
  	}
  
+ 	/* reset \G's expanded-mode flag */
+ 	pset.g_expanded = false;
+ 
  	/* reset \gset trigger */
  	if (pset.gset_prefix)
  	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
new file mode 100644
index 5365629..5e9c249
*** a/src/bin/psql/help.c
--- b/src/bin/psql/help.c
*** slashUsage(unsigned short int pager)
*** 174,179 
--- 174,180 
  	fprintf(output, _("  \\copyright show PostgreSQL usage and distribution terms\n"));
  	fprintf(output, _("  \\errverboseshow most recent error message at maximum verbosity\n"));
  	fprintf(output, _("  \\g [FILE] or ; execute query (and send results to file or |pipe)\n"));
+ 	fprintf(output, _("  \\G [FILE]  as \\g, but force expanded output\n"));
  	fprintf(output, _("  \\gexec execute query, then execute each value in its result\n"));
  	fprintf(output, _("  \\gset [PREFIX] execute query and store results in psql variables\n"));
  	fprintf(output, _("  \\q quit psql\n"));
diff --git a/src/bin/psql/settings.h b/src/bin/psql/settings.h
new file mode 100644
index 4c7c3b1..a13da33
*** a/src/bin/psql/settings.h
--- b/src/bin/psql/settings.h
*** typedef struct _psqlSettings
*** 91,96 
--- 91,97