Re: 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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(at)commandprompt(dot)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(at)gmail(dot)com> [080509 14:43]:
> On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)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(at)highrise(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

>>> "Brendan Jurd" <direvus(at)gmail(dot)com> wrote:
> On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)commandprompt(dot)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 wrapped
Output format is wrapped.
test=> \pset columns 14
Target 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(at)momjian(dot)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(at)gmail(dot)com> [080509 14:43]:
> > On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
> > <alvherre(at)commandprompt(dot)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(at)momjian(dot)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(at)gmail(dot)com> wrote:
> > On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <bruce(at)momjian(dot)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 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.

--
Bruce Momjian <bruce(at)momjian(dot)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(dot)m49Krq529089(at)momjian(dot)us>, Bruce Momjian
<bruce(at)momjian(dot)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(dot)m49Krq529089(at)momjian(dot)us>, Bruce Momjian
> <bruce(at)momjian(dot)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(at)momjian(dot)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.69 rows=269 width=563) (actual time=0.019..0.798 rows=271 loops=1)
-> Materialize (cost=1.03..1.06 rows=3 width=110) (actual time=0.018..0.033 rows=7 loops=271)
-> Seq Scan on pg_language (cost=0.00..1.03 rows=3 width=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(at)commandprompt(dot)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(at)momjian(dot)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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom Lane wrote:
<blockquote cite="mid:24612(dot)1210391398(at)sss(dot)pgh(dot)pa(dot)us" type="cite">
<pre wrap="">Bruce Momjian <a class="moz-txt-link-rfc2396E"
href="mailto:bruce(at)momjian(dot)us">&lt;bruce(at)momjian(dot)us&gt;</a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">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 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.<br>
<br>
                               -Bryce<br>
<br>
PS: it is true, I don't like the missing | bars on the current
version.  I prefer that the grid cells be fully drawn, even if the
contents don't fill the box
</body>
</html>

On Tue, May 13, 2008 at 4:12 PM, Bryce Nesbitt <bryce2(at)obviously(dot)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(at)momjian(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)momjian(dot)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(at)commandprompt(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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 the screen width

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +