Another little thing about psql wrapped expanded output

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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