Sorry, I initially responded only to Josh.  Forwarding to list:

On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus <> 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




Reply via email to