Обсуждение: psql wrapped format default for backslash-d commands
Now that psql '\pset format wrapped' is in CVS, we should consider when we want to use 'wrapped' format by default. I think psql \df and \dT certainly can benefit from wrapped mode. \df+ even displays, though there is quite a bit of wrapping. The attached patch uses wrapped format for \d* output if the current output format is 'aligned'. It certainly helps the \df and \dT because those outputs have normally narrow values with a few wide values that cause aligned output to be much too wide. The downside of the patch is that you can no longer get 'aligned' output for \d* commands anymore because there is no way to know if the user specified 'aligned' or if they are just using the default. This opens the larger question that if 'wrapped' helps with \df and \dT, wouldn't it help with other wide user query output. Now, we can discard this patch and tell people to set their output to 'wrapped' when they issue \d commands, but it is unlikely they will do so. We can also tell people to just default to 'wrapped' in their .psqlrc and then their \d commands and user queries will be in 'wrapped', or we can just default 'format' to 'wrapped' for psql. I have heard a few people say they never way to see 'wrapped' output so perhaps we should do nothing, but I then question whether we want \df and \dT to be hard to read by default. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: src/bin/psql/command.c =================================================================== RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v retrieving revision 1.188 diff -c -c -r1.188 command.c *** src/bin/psql/command.c 8 May 2008 17:04:26 -0000 1.188 --- src/bin/psql/command.c 9 May 2008 17:36:38 -0000 *************** *** 314,319 **** --- 314,324 ---- { char *pattern; bool show_verbose; + enum printFormat saved_format = pset.popt.topt.format; + + /* Use wrapped mode in hopes of displaying output cleanly. */ + if (pset.popt.topt.format == PRINT_ALIGNED) + pset.popt.topt.format = PRINT_WRAPPED; /* We don't do SQLID reduction on the pattern yet */ pattern = psql_scan_slash_option(scan_state, *************** *** 407,412 **** --- 412,419 ---- status = PSQL_CMD_UNKNOWN; } + pset.popt.topt.format = saved_format; /* restore */ + if (pattern) free(pattern); }
On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <bruce@momjian.us> wrote: > Now that psql '\pset format wrapped' is in CVS, we should consider when > we want to use 'wrapped' format by default. I think psql \df and \dT > certainly can benefit from wrapped mode. \df+ even displays, though > there is quite a bit of wrapping. > I for one would definitely like backslash commands with very wide output to be wrapped by default. > The attached patch uses wrapped format for \d* output if the current > output format is 'aligned'. It certainly helps the \df and \dT because > those outputs have normally narrow values with a few wide values that > cause aligned output to be much too wide. The downside of the patch is > that you can no longer get 'aligned' output for \d* commands anymore > because there is no way to know if the user specified 'aligned' or if > they are just using the default. > Doesn't this suggest that we need an "auto" formatting mode which has the semantics "let psql decide what format mode I want"? Then the people who object to wrapped mode can just set formatting to aligned explicitly and be done with it. I seem to recall there was some discussion of an "auto" mode in the original wrapping thread, but if there was any meaningful conclusion I lost it in amongst the width detection flame war. Cheers, BJ
Brendan Jurd escribió: > On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <bruce@momjian.us> wrote: > > Now that psql '\pset format wrapped' is in CVS, we should consider when > > we want to use 'wrapped' format by default. I think psql \df and \dT > > certainly can benefit from wrapped mode. \df+ even displays, though > > there is quite a bit of wrapping. > > I for one would definitely like backslash commands with very wide > output to be wrapped by default. (At least) one place where I would not like it is in \df+, because wrapped function output would be more difficult to read. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Brendan Jurd escribió: >> I for one would definitely like backslash commands with very wide >> output to be wrapped by default. > > (At least) one place where I would not like it is in \df+, because > wrapped function output would be more difficult to read. > I am a bit conflicted about wrapping on \df. I agree that wrapped function code is difficult to read, but what we've got now is difficult to read too. Which of the two is more difficult is really a matter of personal taste. I guess with \df you have to accept that it's always going to be ugly, unless you have a very wide terminal (or very short function definitions!). Cheers, BJ
* Brendan Jurd <direvus@gmail.com> [080509 14:43]: > On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera > <alvherre@commandprompt.com> wrote: > > Brendan Jurd escribió: > >> I for one would definitely like backslash commands with very wide > >> output to be wrapped by default. > > > > (At least) one place where I would not like it is in \df+, because > > wrapped function output would be more difficult to read. > > > > I am a bit conflicted about wrapping on \df. I agree that wrapped > function code is difficult to read, but what we've got now is > difficult to read too. Which of the two is more difficult is really a > matter of personal taste. I guess with \df you have to accept that > it's always going to be ugly, unless you have a very wide terminal (or > very short function definitions!). Isn't that what $PAGER is for? $PAGER is the main reason why *I* don't want the wrapped format. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Brendan Jurd wrote: [ email paragraphs reordered.] > I seem to recall there was some discussion of an "auto" mode in the > original wrapping thread, but if there was any meaningful conclusion I > lost it in amongst the width detection flame war. I wasn't going to bring up the 'auto' idea yet because it might confuse things, but I guess I should address it now. "wrapped" format doesn't wrap if the column headings don't fit the screen width _without_ wrapping (it then uses 'aligned'). My idea was for an 'auto' format mode to use wrapped, or expanded if wrapped can't be displayed. > > The attached patch uses wrapped format for \d* output if the current > > output format is 'aligned'. It certainly helps the \df and \dT because > > those outputs have normally narrow values with a few wide values that > > cause aligned output to be much too wide. The downside of the patch is > > that you can no longer get 'aligned' output for \d* commands anymore > > because there is no way to know if the user specified 'aligned' or if > > they are just using the default. > > > > Doesn't this suggest that we need an "auto" formatting mode which has > the semantics "let psql decide what format mode I want"? The big problem is unless we default psql to 'auto' we can't know if they really want 'aligned', 'wrapped', or whatever looks good on the screen, 'auto'. > Then the people who object to wrapped mode can just set formatting to > aligned explicitly and be done with it. Right, but 'wrapped' is kind of a dramatic change so we have to be sure most people wanted 'wrapped' (or 'auto'). I think the way we did the detection defaults will help because a default of 'auto' will only affect screen output, by default. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>>> "Brendan Jurd" <direvus@gmail.com> wrote: > On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <bruce@momjian.us> wrote: >> Now that psql '\pset format wrapped' is in CVS, we should consider when >> we want to use 'wrapped' format by default. I think psql \df and \dT >> certainly can benefit from wrapped mode. \df+ even displays, though >> there is quite a bit of wrapping. > > I for one would definitely like backslash commands with very wide > output to be wrapped by default. I would prefer the default to be the current 8.2 behavior. As long as I can configure that easily it's not a huge deal, but I may have to deal with some users whose ad hoc queries feed into spreadsheets or some such that will be broken until they do something new. I currently use \x to view results about once a month (on average). I expect to find wrapped columns useful about that often. I cut and paste multi-line unwrapped output from my console window practically daily, and the wrapping would make that painful. That just got me thinking -- has anyone tried this out with EXPLAIN ANALYZE output yet? -Kevin
Brendan Jurd wrote: > On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera > <alvherre@commandprompt.com> wrote: > > Brendan Jurd escribi?: > >> I for one would definitely like backslash commands with very wide > >> output to be wrapped by default. > > > > (At least) one place where I would not like it is in \df+, because > > wrapped function output would be more difficult to read. > > > > I am a bit conflicted about wrapping on \df. I agree that wrapped > function code is difficult to read, but what we've got now is > difficult to read too. Which of the two is more difficult is really a > matter of personal taste. I guess with \df you have to accept that > it's always going to be ugly, unless you have a very wide terminal (or > very short function definitions!). Oh, good point. I hadn't thought about function bodies being displayed. Here is an example: test=> \pset format wrappedOutput format is wrapped.test=> \pset columns 14Target width for "wrapped" format is 14.test=>select prosrc from pg_proc where proname = 'xx'; prosrc-------------- SELECT 'a': :text WHERE 1 = 1(1 row) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Aidan Van Dyk wrote: -- Start of PGP signed section. > * Brendan Jurd <direvus@gmail.com> [080509 14:43]: > > On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera > > <alvherre@commandprompt.com> wrote: > > > Brendan Jurd escribi?: > > >> I for one would definitely like backslash commands with very wide > > >> output to be wrapped by default. > > > > > > (At least) one place where I would not like it is in \df+, because > > > wrapped function output would be more difficult to read. > > > > > > > I am a bit conflicted about wrapping on \df. I agree that wrapped > > function code is difficult to read, but what we've got now is > > difficult to read too. Which of the two is more difficult is really a > > matter of personal taste. I guess with \df you have to accept that > > it's always going to be ugly, unless you have a very wide terminal (or > > very short function definitions!). > > Isn't that what $PAGER is for? > > $PAGER is the main reason why *I* don't want the wrapped format. Not all pagers scroll width-wise --- in fact I thought most didn't. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Kevin Grittner wrote: > >>> "Brendan Jurd" <direvus@gmail.com> wrote: > > On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <bruce@momjian.us> > wrote: > >> Now that psql '\pset format wrapped' is in CVS, we should consider > when > >> we want to use 'wrapped' format by default. I think psql \df and > \dT > >> certainly can benefit from wrapped mode. \df+ even displays, > though > >> there is quite a bit of wrapping. > > > > I for one would definitely like backslash commands with very wide > > output to be wrapped by default. > > I would prefer the default to be the current 8.2 behavior. As long as > I can configure that easily it's not a huge deal, but I may have to > deal with some users whose ad hoc queries feed into spreadsheets or > some such that will be broken until they do something new. > > I currently use \x to view results about once a month (on average). I > expect to find wrapped columns useful about that often. I cut and > paste multi-line unwrapped output from my console window practically > daily, and the wrapping would make that painful. That just got me > thinking -- has anyone tried this out with EXPLAIN ANALYZE output yet? No, but I just tried it: test=> \pset format wrappedOutput format is wrapped.test=> \pset columns 50Target width for "wrapped" format is 50.test=>explain analyze select * from pg_type, pg_language; QUERY PLAN--------------------------------------------------Nested Loop (cost=1.03..25.86 rows=807 width=66 5) (actual time=0.037..4.528rows=807 loops=1) -> Seq Scan on pg_type (cost=0.00..8.69 rows =269 width=555) (actual time=0.018..0.377rows=2 69 loops=1) -> Materialize (cost=1.03..1.06 rows=3 width =110) (actual time=0.001..0.005 rows=3loops=269 ) -> Seq Scan on pg_language (cost=0.00. .1.03 rows=3 width=110) (actual time=0.004..0.00 7 rows=3loops=1) Total runtime: 5.490 ms(5 rows) Of course, running it on a 50-column display in 'aligned' mode isn't going to look good either. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>>> On Fri, May 9, 2008 at 3:53 PM, in message <200805092053.m49Krq529089@momjian.us>, Bruce Momjian <bruce@momjian.us> wrote: > test=> \pset format wrapped > Output format is wrapped. > test=> \pset columns 50 > Target width for "wrapped" format is 50. > test=> explain analyze select * from pg_type, pg_language; > QUERY PLAN > -------------------------------------------------- > Nested Loop (cost=1.03..25.86 rows=807 width=66 > 5) (actual time=0.037..4.528 rows=807 loops=1) > -> Seq Scan on pg_type (cost=0.00..8.69 rows > =269 width=555) (actual time=0.018..0.377 rows=2 > 69 loops=1) > -> Materialize (cost=1.03..1.06 rows=3 width > =110) (actual time=0.001..0.005 rows=3 loops=269 > ) > -> Seq Scan on pg_language (cost=0.00. > .1.03 rows=3 width=110) (actual time=0.004..0.00 > 7 rows=3 loops=1) > Total runtime: 5.490 ms > (5 rows) > > Of course, running it on a 50-column display in 'aligned' mode isn't > going to look good either. With current production software, if I run in a 50 column window and cut and paste into email, there aren't any line-ends in the email as there would be with wrapped format. -Kevin
Kevin Grittner wrote: > >>> On Fri, May 9, 2008 at 3:53 PM, in message > <200805092053.m49Krq529089@momjian.us>, Bruce Momjian > <bruce@momjian.us> wrote: > > > test=> \pset format wrapped > > Output format is wrapped. > > test=> \pset columns 50 > > Target width for "wrapped" format is 50. > > test=> explain analyze select * from pg_type, pg_language; > > QUERY PLAN > > -------------------------------------------------- > > Nested Loop (cost=1.03..25.86 rows=807 width=66 > > 5) (actual time=0.037..4.528 rows=807 loops=1) > > -> Seq Scan on pg_type (cost=0.00..8.69 rows > > =269 width=555) (actual time=0.018..0.377 rows=2 > > 69 loops=1) > > -> Materialize (cost=1.03..1.06 rows=3 width > > =110) (actual time=0.001..0.005 rows=3 loops=269 > > ) > > -> Seq Scan on pg_language (cost=0.00. > > .1.03 rows=3 width=110) (actual time=0.004..0.00 > > 7 rows=3 loops=1) > > Total runtime: 5.490 ms > > (5 rows) > > > > Of course, running it on a 50-column display in 'aligned' mode isn't > > going to look good either. > > With current production software, if I run in a 50 column window and > cut and paste into email, there aren't any line-ends in the email as > there would be with wrapped format. I think that depends on what terminal you are using, but I do see some of my terminal programs understand when wrapping happens and adjust the cut/paste behavior. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian escribió: > Of course, running it on a 50-column display in 'aligned' mode isn't > going to look good either. This is what I get by pasting from a 50-column aligned psql (8.3): QUERY PLAN -------------------------------------------------------------------------------------------------------------------Nested Loop (cost=1.03..25.86 rows=807 width=673) (actual time=4.349..20.973 rows=1897 loops=1) -> Seq Scan on pg_type (cost=0.00..8.69rows=269 width=563) (actual time=0.019..0.798 rows=271 loops=1) -> Materialize (cost=1.03..1.06 rows=3width=110) (actual time=0.018..0.033 rows=7 loops=271) -> Seq Scan on pg_language (cost=0.00..1.03 rows=3width=110) (actual time=4.296..4.312 rows=7 loops=1)Total runtime: 35.041 ms (5 lignes) No unwanted line breaks. Of course, on the terminal it looks narrower, but this doesn't affect cut'n paste behavior. My conclusion is that we have to make very sure that "wrapped" is not the default for explain. FWIW this is expanded output: alvherre=# \x Affichage étendu activé. alvherre=# explain analyze select * from pg_type, pg_language; -[ RECORD 1 ]----------------------------------------------------------------------------------------------------------------- QUERY PLAN | Nested Loop (cost=1.03..25.86 rows=807 width=673) (actual time=0.055..15.648 rows=1897 loops=1) -[ RECORD 2 ]----------------------------------------------------------------------------------------------------------------- QUERY PLAN | -> Seq Scan on pg_type (cost=0.00..8.69 rows=269 width=563) (actual time=0.019..0.623 rows=271 loops=1) -[ RECORD 3 ]----------------------------------------------------------------------------------------------------------------- QUERY PLAN | -> Materialize (cost=1.03..1.06 rows=3 width=110) (actual time=0.002..0.016 rows=7 loops=271) -[ RECORD 4 ]----------------------------------------------------------------------------------------------------------------- QUERY PLAN | -> Seq Scan on pg_language (cost=0.00..1.03 rows=3 width=110) (actual time=0.005..0.021 rows=7 loops=1) -[ RECORD 5 ]----------------------------------------------------------------------------------------------------------------- QUERY PLAN | Total runtime: 19.649 ms -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>>> Alvaro Herrera <alvherre@commandprompt.com> wrote: > Bruce Momjian escribió: > My conclusion is that we have to make very sure that "wrapped" is not > the default for explain. This will cause me similar pain in other areas. I'm glad I thought of an example with which others could easily identify. -Kevin
Bruce Momjian <bruce@momjian.us> writes: > Now that psql '\pset format wrapped' is in CVS, we should consider when > we want to use 'wrapped' format by default. After experimenting for a bit, I'd say "never". This output format is extremely ugly. Maybe if it had enough smarts not to break in the middle of words ... regards, tom lane
Tom Lane wrote: <blockquote cite="mid:24612.1210391398@sss.pgh.pa.us" type="cite"><pre wrap="">Bruce Momjian <a class="moz-txt-link-rfc2396E"href="mailto:bruce@momjian.us"><bruce@momjian.us></a> writes: </pre><blockquote type="cite"><prewrap="">Now that psql '\pset format wrapped' is in CVS, we should consider when we want to use 'wrapped' format by default. </pre></blockquote><pre wrap=""> After experimenting for a bit, I'd say "never". This output format is extremely ugly. Maybe if it had enough smarts not to break in the middle of words ... regards, tom lane </pre></blockquote> Yet, wrapped is the same as aligned, if the lines fit!<br/><br /> Ugly to wrap? Yes.<br /> Uglier than the sea of pipes you get when aligned output wraps itself?<br /><br/> Well I suppose you have to pick your preferred version of ugly. I find it very hard to line up columns when presentedwith a sea of pipes, and highly annoying to constantly adjust my window width to see a query, especially if onlyone or two rows are too large.<br /><br /> -Bryce<br /><br /> PS: it is true, I don'tlike the missing | bars on the current version. I prefer that the grid cells be fully drawn, even if the contents don'tfill the box
On Tue, May 13, 2008 at 4:12 PM, Bryce Nesbitt <bryce2@obviously.com> wrote: > > Tom Lane wrote: >> >> After experimenting for a bit, I'd say "never". This output format is >> extremely ugly. Maybe if it had enough smarts not to break in the >> middle of words ... >> regards, tom lane > > Yet, wrapped is the same as aligned, if the lines fit! > > Ugly to wrap? Yes. > Uglier than the sea of pipes you get when aligned output wraps itself? > > Well I suppose you have to pick your preferred version of ugly. I find it > very hard to line up columns when presented with a sea of pipes, and highly > annoying to constantly adjust my window width to see a query, especially if > only one or two rows are too large. > I really like the idea of wrapping, but after playing with the format a bit myself, I have to agree with Tom that breaking in the middle of words produces some very nasty output. If the format could be improved to only wrap on word boudaries, that would increase its appeal dramatically. Anybody got a rough idea how difficult it would be to add word-awareness int o the wrapping code? Cheers, BJ
Brendan Jurd wrote: > I really like the idea of wrapping, but after playing with the format > a bit myself, I have to agree with Tom that breaking in the middle of > words produces some very nasty output. > > If the format could be improved to only wrap on word boudaries, that > would increase its appeal dramatically. > > Anybody got a rough idea how difficult it would be to add > word-awareness int o the wrapping code? > > Cheers, > BJ > It's not that hard to do. I chose not to, when writing the patch, because it makes the result flow over many more lines. And regardless, it pretty much has to cut long "words", of which there are many in typical SQL output. And, I hardly ever read actual large blocks of English at the SQL prompt, so: designing for that use case did not float my boat at the time. And, word wrapping messes with the cell contents more than I was comfortable doing. With the current wrapping all whitespace is preserved and apparent. But, if your boat is floated, then by all means go for it. -Bryce
Bryce Nesbitt wrote: > It's not that hard to do. > > I chose not to, when writing the patch, because it makes the result flow > over many more lines. > And regardless, it pretty much has to cut long "words", of which there > are many in typical SQL output. > And, I hardly ever read actual large blocks of English at the SQL > prompt, so: designing for that use case did > not float my boat at the time. > And, word wrapping messes with the cell contents more than I was > comfortable doing. With the current wrapping all whitespace is preserved > and apparent. > > But, if your boat is floated, then by all means go for it. Yea, you could probably call it a 'chopped' format rather than a 'wrapped' format. While I got a lot of feedback on screen width detection for wrapped, I got little freedback on the display format. We can address that now. I think we can wrap if there is whitespace within a few characters before the break point, and use a dash if we have to break a word. Is that what people want? Also, about the format 'auto' idea that uses expanded display, I am thinking because expanded is a separate setting and not a format, I should just add a possible 'auto' value to the expanded format that could be triggered by either 'aligned' or 'wrapped' formats when the output doesn't fit on the screen. (In hindsight, I think we should have had pager be on/auto/off rather than always/on/off; the later is kind of confusing and would be inconsistent if I add 'auto' to expanded.) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > I think we can wrap if there is whitespace within a few characters > before the break point, and use a dash if we have to break a word. Is > that what people want? Ugh. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes: > Bruce Momjian wrote: >> I think we can wrap if there is whitespace within a few characters >> before the break point, and use a dash if we have to break a word. Is >> that what people want? > Ugh. Inserting dashes would be a truly horrid idea: "ab" and "a-b" mean quite different things within a function, for instance. regards, tom lane
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Bruce Momjian wrote: > >> I think we can wrap if there is whitespace within a few characters > >> before the break point, and use a dash if we have to break a word. Is > >> that what people want? > > > Ugh. > > Inserting dashes would be a truly horrid idea: "ab" and "a-b" mean > quite different things within a function, for instance. The idea would be for the dash to appear outside where normal data appears: internal | RI_FKey_cas-| referential ; cade_del ; integrity If we don't allow a dash, I think wrapping on word boundaries will be impossible because we can't guarantee no word breaks, and I think if we sometimes word break we had better indicate that somehow. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > The idea would be for the dash to appear outside where normal data > appears: > > internal | RI_FKey_cas-| referential > ; cade_del ; integrity > > If we don't allow a dash, I think wrapping on word boundaries will be > impossible because we can't guarantee no word breaks, and I think if we > sometimes word break we had better indicate that somehow. I think the behaviour would be better if we were able to only break on words, and make columns wider on those where words wouldn't fit. However, this would mean that the column setting is only a hint, not a hard limit :-( which doesn't sound so good either. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera <alvherre@commandprompt.com> writes: > I think the behaviour would be better if we were able to only break on > words, and make columns wider on those where words wouldn't fit. select repeat('xyzzy', 100000); Now admittedly our current handling of this isn't all that great either, but you can't design around the assumption that a nice break will always be possible. regards, tom lane
Alvaro Herrera wrote: > Bruce Momjian wrote: > > > The idea would be for the dash to appear outside where normal data > > appears: > > > > internal | RI_FKey_cas-| referential > > ; cade_del ; integrity > > > > If we don't allow a dash, I think wrapping on word boundaries will be > > impossible because we can't guarantee no word breaks, and I think if we > > sometimes word break we had better indicate that somehow. > > I think the behaviour would be better if we were able to only break on > words, and make columns wider on those where words wouldn't fit. Consider \df, where a few of the function names are pretty long; preventing wrapping of those would seriously limit the usefulness of wrapping mode. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
There's another serious usability problem here, which is that the pager ability is not being used correctly. Consider the \df+ tg_* query I used as example for another bug report. psql says that it is 27 rows; I have my window taller than that (47 lines right now), yet the output is actually *a lot* longer than 27 rows (598 lines), due to the embedded newlines in the functions source. Yet the pager is not used, and so the whole thing scrolls past. Also: someone else said that if the pager mode is "auto", then the pager should be used not only when the output is _longer_ than the screen, but also if it's _wider_. I agree with that. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > There's another serious usability problem here, which is that the pager > ability is not being used correctly. Consider the \df+ tg_* query I > used as example for another bug report. psql says that it is 27 rows; I > have my window taller than that (47 lines right now), yet the output is > actually *a lot* longer than 27 rows (598 lines), due to the embedded > newlines in the functions source. Yet the pager is not used, and so the > whole thing scrolls past. Yes, I mentioned that as a known bug, but when we exceed the screen width and wrap over we don't adjust the pager either, so I figured it was OK. > Also: someone else said that if the pager mode is "auto", then the pager > should be used not only when the output is _longer_ than the screen, but > also if it's _wider_. I agree with that. Hmmm, we could do that. Though remember the 'pager' variable is confusing; automatic is 'on', and 'always' is always. Changing that to 'on/auto/off' was a suggestion I just made, and doing the same for expanded. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bryce Nesbitt wrote: > > Brendan Jurd wrote: > > I really like the idea of wrapping, but after playing with the format > > a bit myself, I have to agree with Tom that breaking in the middle of > > words produces some very nasty output. > > > > If the format could be improved to only wrap on word boudaries, that > > would increase its appeal dramatically. > > > > Anybody got a rough idea how difficult it would be to add > > word-awareness int o the wrapping code? > > I chose not to, when writing the patch, because it makes the result flow > over many more lines. > And regardless, it pretty much has to cut long "words", of which there > are many in typical SQL output. > And, I hardly ever read actual large blocks of English at the SQL > prompt, so: designing for that use case did > not float my boat at the time. > And, word wrapping messes with the cell contents more than I was > comfortable doing. With the current wrapping all whitespace is preserved > and apparent. > > But, if your boat is floated, then by all means go for it. Added to TODO: o Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width. Currently, "wrapped" format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification. http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php http://www.w3.org/TR/CSS21/tables.html#auto-table-layout -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Also, about the format 'auto' idea that uses expanded display, I am > thinking because expanded is a separate setting and not a format, I > should just add a possible 'auto' value to the expanded format that > could be triggered by either 'aligned' or 'wrapped' formats when the > output doesn't fit on the screen. > > (In hindsight, I think we should have had pager be on/auto/off rather > than always/on/off; the later is kind of confusing and would be > inconsistent if I add 'auto' to expanded.) Added to psql TODO: o Add "auto" expanded mode that outputs in expanded format if "wrapped" mode can't wrap the output to thescreen width -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +