Thread: Another little thing about psql wrapped expanded output
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.
Cheers,
> 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
psql -c 'select * from pg_stats' -x
Cheers,
Jeff