Thread: [HACKERS] One-shot expanded output in psql using \G
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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
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
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
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
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
* 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
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
* 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.
* 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
* 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;
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
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
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
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
* 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
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
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
"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
* 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
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
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
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
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
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
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.
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
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
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
The majority of voices here was in favor of using \gx, so here is another version of the same patch which implements that. Christoph -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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
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
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
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
intexpanded; /* 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
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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
* 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
I've tested the new \gx against 10beta and current git HEAD. Actually one of my favourite features of PostgreSQL 10! Howeverin my environment it was behaving strangely. After some debugging I found that \gx does not work if you have \setFETCH_COUNT n before. Please find attached a patch that fixes this incl. new regression test. Best regards, Tobias -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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! Howeverin my environment it was behaving strangely. After some debugging I found that \gx does not work if you have \setFETCH_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
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
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 \setFETCH_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
* 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 \setFETCH_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
* 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 \setFETCH_COUNT n before. Please find attached a patch that fixes this incl. new regression test. Fixed in 0cdc3e4. Thanks for the report! Stephen