Thread: Another little thing about psql wrapped expanded output

Another little thing about psql wrapped expanded output

From
Tom Lane
Date:
regression=# \pset format wrapped
Output format is wrapped.
regression=# \x
Expanded display is on.
regression=# select * from int8_tbl;
-[ RECORD 1 ]-------------------------------------------------------------------
q1 | 123
q2 | 456
-[ RECORD 2 ]-------------------------------------------------------------------
q1 | 123
q2 | 4567890123456789
-[ RECORD 3 ]-------------------------------------------------------------------
q1 | 4567890123456789
q2 | 123
-[ RECORD 4 ]-------------------------------------------------------------------
q1 | 4567890123456789
q2 | 4567890123456789
-[ RECORD 5 ]-------------------------------------------------------------------
q1 | 4567890123456789
q2 | -4567890123456789

Notice that the dashed lines go all the way to the right margin of my
80-column terminal window, even though the data requires no more than
22 columns.  While this doesn't look so awful as-is, when I'm working
in a very wide window it starts to look a little silly.

The behavior I'd have expected is that if the data is narrower than
the window, the lines only go to the right margin of the data.  This
is a trivial change to the logic in print_aligned_vertical, but before
I go make it, does anyone want to argue that the current behavior is
preferable to that?
        regards, tom lane



Re: Another little thing about psql wrapped expanded output

From
David Fetter
Date:
On Tue, Dec 01, 2015 at 11:20:53AM -0500, Tom Lane wrote:
> regression=# \pset format wrapped
> Output format is wrapped.
> regression=# \x
> Expanded display is on.
> regression=# select * from int8_tbl;
> -[ RECORD 1 ]-------------------------------------------------------------------
> q1 | 123
> q2 | 456
> -[ RECORD 2 ]-------------------------------------------------------------------
> q1 | 123
> q2 | 4567890123456789
> -[ RECORD 3 ]-------------------------------------------------------------------
> q1 | 4567890123456789
> q2 | 123
> -[ RECORD 4 ]-------------------------------------------------------------------
> q1 | 4567890123456789
> q2 | 4567890123456789
> -[ RECORD 5 ]-------------------------------------------------------------------
> q1 | 4567890123456789
> q2 | -4567890123456789
> 
> Notice that the dashed lines go all the way to the right margin of my
> 80-column terminal window, even though the data requires no more than
> 22 columns.  While this doesn't look so awful as-is, when I'm working
> in a very wide window it starts to look a little silly.
> 
> The behavior I'd have expected is that if the data is narrower than
> the window, the lines only go to the right margin of the data.  This
> is a trivial change to the logic in print_aligned_vertical, but before
> I go make it, does anyone want to argue that the current behavior is
> preferable to that?

+1 for changing it.

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

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



Re: Another little thing about psql wrapped expanded output

From
Josh Berkus
Date:
On 12/01/2015 11:20 AM, Tom Lane wrote:
> Notice that the dashed lines go all the way to the right margin of my
> 80-column terminal window, even though the data requires no more than
> 22 columns.  While this doesn't look so awful as-is, when I'm working
> in a very wide window it starts to look a little silly.
> 
> The behavior I'd have expected is that if the data is narrower than
> the window, the lines only go to the right margin of the data.  This
> is a trivial change to the logic in print_aligned_vertical, but before
> I go make it, does anyone want to argue that the current behavior is
> preferable to that?

If you're fixing the dashed-line code, is there a way to say that we
never have more than a reasonable number of dashes (ideally, the width
of the terminal) no matter how wide the data is?  Having 4000 dashes
because of large text on one row is kinda painful, and not at all useful.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



Fwd: Another little thing about psql wrapped expanded output

From
Jeff Janes
Date:
Sorry, I initially responded only to Josh.  Forwarding to list:



On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 12/01/2015 11:20 AM, Tom Lane wrote:
>> Notice that the dashed lines go all the way to the right margin of my
>> 80-column terminal window, even though the data requires no more than
>> 22 columns.  While this doesn't look so awful as-is, when I'm working
>> in a very wide window it starts to look a little silly.
>>
>> The behavior I'd have expected is that if the data is narrower than
>> the window, the lines only go to the right margin of the data.  This
>> is a trivial change to the logic in print_aligned_vertical, but before
>> I go make it, does anyone want to argue that the current behavior is
>> preferable to that?
>
> If you're fixing the dashed-line code, is there a way to say that we
> never have more than a reasonable number of dashes (ideally, the width
> of the terminal) no matter how wide the data is?  Having 4000 dashes
> because of large text on one row is kinda painful, and not at all useful.

If you use \pset format wrapped, then this automatically happens as part of the data wrapping.

If you use the default format (\pset format aligned) in expanded mode, then I agree with you we shouldn't print a half screen full of dashes to separate every tuple.   However, a very simple patch to do exactly what you want is what was originally submitted, and was rejected in favor of instead implementing this new feature of \pset format wrapped for expanded mode.  Since it was rejected I was reluctant to bring it up again, but like you, I do still think it is a good idea.

You could argue that it is the pager's job to deal with this.  If the pager chooses to wrap the parts that don't fit on the screen, it should truncate the separators after one line's width rather than wrapping them.  But if it instead shows you a sliding slice of an infinitely-wide screen, then it should keep the separators.  But since the pager has no way of knowing that the dashes are separators and not actual data, the pager can't reasonably do a good job of that.  

For those who can't follow my hand-waving, try this:

psql -c 'select * from pg_stats' -x








Cheers,

Jeff

Attachment

Re: Fwd: Another little thing about psql wrapped expanded output

From
Tom Lane
Date:
Jeff Janes <jeff.janes@gmail.com> writes:
> On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> If you're fixing the dashed-line code, is there a way to say that we
>> never have more than a reasonable number of dashes (ideally, the width
>> of the terminal) no matter how wide the data is?  Having 4000 dashes
>> because of large text on one row is kinda painful, and not at all useful.

> If you use the default format (\pset format aligned) in expanded mode, then
> I agree with you we shouldn't print a half screen full of dashes to
> separate every tuple.

Don't think I agree.  Suppose that you have a wider-than-screen table
and you use a pager to scroll left and right in that.  If we shorten the
dashed lines, then once you scroll to the right of wherever they stop,
you lose that visual cue separating the rows.  This matters a lot if
only a few of the column values are very wide: everywhere else, there's
gonna be lots of whitespace.

In the situation you are describing, you've already pretty much lost
user-friendliness of the display, and the only way to get it back is
to use a suitable pager (or make the window bigger, but that only goes
so far).  So I don't think we should optimize the non-pager case at
the expense of the pager case.

It's possible that it'd be worth the trouble to give psql two operating
modes, one for pagers with left-right scroll ability and one for those
without.  But that would be a good deal more work than what I propose
to do at the moment.
        regards, tom lane



Re: Fwd: Another little thing about psql wrapped expanded output

From
Josh Berkus
Date:
On 12/02/2015 05:24 PM, Tom Lane wrote:
> Don't think I agree.  Suppose that you have a wider-than-screen table
> and you use a pager to scroll left and right in that.  If we shorten the
> dashed lines, then once you scroll to the right of wherever they stop,
> you lose that visual cue separating the rows.  This matters a lot if
> only a few of the column values are very wide: everywhere else, there's
> gonna be lots of whitespace.

What pager lets me scroll right infinitely?  Because I wanna install that.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



Re: Fwd: Another little thing about psql wrapped expanded output

From
David Fetter
Date:
On Wed, Dec 02, 2015 at 10:36:56PM -0500, Josh Berkus wrote:
> On 12/02/2015 05:24 PM, Tom Lane wrote:
> > Don't think I agree.  Suppose that you have a wider-than-screen table
> > and you use a pager to scroll left and right in that.  If we shorten the
> > dashed lines, then once you scroll to the right of wherever they stop,
> > you lose that visual cue separating the rows.  This matters a lot if
> > only a few of the column values are very wide: everywhere else, there's
> > gonna be lots of whitespace.
> 
> What pager lets me scroll right infinitely?  Because I wanna install that.

I don't know about infinitely, but at least with the -S (no wrap)
option, less lets you use left- and right-arrow, prefixed by
multipliers, if you like, to scroll horizontally

And now I have learned something new about a pager I've used every day
for decades.

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

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



Re: Fwd: Another little thing about psql wrapped expanded output

From
Jeff Janes
Date:
On Wed, Dec 2, 2015 at 7:59 PM, David Fetter <david@fetter.org> wrote:
> On Wed, Dec 02, 2015 at 10:36:56PM -0500, Josh Berkus wrote:
>> On 12/02/2015 05:24 PM, Tom Lane wrote:
>> > Don't think I agree.  Suppose that you have a wider-than-screen table
>> > and you use a pager to scroll left and right in that.  If we shorten the
>> > dashed lines, then once you scroll to the right of wherever they stop,
>> > you lose that visual cue separating the rows.  This matters a lot if
>> > only a few of the column values are very wide: everywhere else, there's
>> > gonna be lots of whitespace.
>>
>> What pager lets me scroll right infinitely?  Because I wanna install that.
>
> I don't know about infinitely, but at least with the -S (no wrap)
> option, less lets you use left- and right-arrow, prefixed by
> multipliers, if you like, to scroll horizontally
>
> And now I have learned something new about a pager I've used every day
> for decades.


And even if you don't specify -S, 'less' will jump into that mode
anyway as soon as you hit the right array.  It starts out wrapping,
but hit the right arrow and it undoes the wrap.  So I often do hit '1'
right arrow to get out of the wrap situation described above.  I do
lose the leftmost character on the screen.  Then you can left-arrow
all the way back to the left, and it jumps back into wrap mode.

Pretty darn useful at times.  Now, if I could just find a way to tell
'less' after-the-fact "pretend I started you up with the -X flag".
Once I find the part I want, I want to quit the pager without clearing
that stuff off of the screen.  Sometimes.

Cheers,

Jeff



Re: Fwd: Another little thing about psql wrapped expanded output

From
Robert Haas
Date:
On Wed, Dec 2, 2015 at 5:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus <josh@agliodbs.com> wrote:
>>> If you're fixing the dashed-line code, is there a way to say that we
>>> never have more than a reasonable number of dashes (ideally, the width
>>> of the terminal) no matter how wide the data is?  Having 4000 dashes
>>> because of large text on one row is kinda painful, and not at all useful.
>
>> If you use the default format (\pset format aligned) in expanded mode, then
>> I agree with you we shouldn't print a half screen full of dashes to
>> separate every tuple.
>
> Don't think I agree.  Suppose that you have a wider-than-screen table
> and you use a pager to scroll left and right in that.  If we shorten the
> dashed lines, then once you scroll to the right of wherever they stop,
> you lose that visual cue separating the rows.  This matters a lot if
> only a few of the column values are very wide: everywhere else, there's
> gonna be lots of whitespace.

For what it's worth, I'm with Josh and Jeff.  My pager, like nearly
everybody else's, is less.  And it's not stupid to have a behavior
that works reasonably with less's default settings.  I haven't kept a
count of the number of times I've had to scroll down through endless
pages of dashes in order to find some data that's not dashes, but it's
surely quite a few.

Your point is also valid, so I don't mean to detract from that.  But
the status quo is definitely annoying.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Fwd: Another little thing about psql wrapped expanded output

From
Jim Nasby
Date:
On 12/8/15 1:36 PM, Robert Haas wrote:
> Your point is also valid, so I don't mean to detract from that.  But
> the status quo is definitely annoying.

+1, and I even use -S.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com



Re: Fwd: Another little thing about psql wrapped expanded output

From
"David G. Johnston"
Date:
On Tue, Dec 8, 2015 at 12:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Dec 2, 2015 at 5:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus <josh@agliodbs.com> wrote:
>>> If you're fixing the dashed-line code, is there a way to say that we
>>> never have more than a reasonable number of dashes (ideally, the width
>>> of the terminal) no matter how wide the data is?  Having 4000 dashes
>>> because of large text on one row is kinda painful, and not at all useful.
>
>> If you use the default format (\pset format aligned) in expanded mode, then
>> I agree with you we shouldn't print a half screen full of dashes to
>> separate every tuple.
>
> Don't think I agree.  Suppose that you have a wider-than-screen table
> and you use a pager to scroll left and right in that.  If we shorten the
> dashed lines, then once you scroll to the right of wherever they stop,
> you lose that visual cue separating the rows.  This matters a lot if
> only a few of the column values are very wide: everywhere else, there's
> gonna be lots of whitespace.

For what it's worth, I'm with Josh and Jeff.  My pager, like nearly
everybody else's, is less.  And it's not stupid to have a behavior
that works reasonably with less's default settings.  I haven't kept a
count of the number of times I've had to scroll down through endless
pages of dashes in order to find some data that's not dashes, but it's
surely quite a few.

Your point is also valid, so I don't mean to detract from that.  But
the status quo is definitely annoying.

​for those wishing to change the status quo the question is whether there needs to be a way to get back to the present behavior and, more generally, configure the behavior to taste while still having a reasonable default.

Losing a bit of usability in not being able to identify record boundaries while viewing off to the right seems is a trade-off that feels right to me.  During interactive use SELECT * is quite useful but is hampered on relations that just happen to have a wide column that you don't care about but also don't want to waste the effort to specify all column names except that one.

​So +1 from me.

David J.​