Re: wrapping in extended mode doesn't work well with default pager

Emre Hasegeli <emre(at)hasegeli(dot)com> writes:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>> I am checking feature
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=6513633b94173fc1d9e2b213c43f9422ddbf5faa
>>
>> It works perfect with pager "less", but it works badly with default "more"

> I do not think so. It looks broken with or without any pager when
> border != 2. Your less configuration might be hiding the problem from you.

This seems broken in several ways. I tried this test case:

regression=# \x \pset format wrapped
Expanded display (expanded) is on.
Output format (format) is wrapped.
regression=# select * from pg_proc where prolang!=12;

In 9.3, the output looks like this:

-[ RECORD 1 ]---+---------------------------------------------------------------
--------------------------------------------------------------------------------
------------------------------------
proname | to_timestamp
pronamespace | 11
proowner | 10
prolang | 14
procost | 1
prorows | 0
provariadic | 0
protransform | -
...

In HEAD, I see:

-[ RECORD 1 ]---+---------------------------------------------------------------
proname | to_timestamp

pronamespace | 11

proowner | 10

prolang | 14

procost | 1

prorows | 0

provariadic | 0

protransform | -

After "\pset columns 77" it looks a little better:

-[ RECORD 1 ]---+------------------------------------------------------------
proname | to_timestamp
pronamespace | 11
proowner | 10
prolang | 14
procost | 1
prorows | 0
provariadic | 0
protransform | -
proisagg | f
proiswindow | f

but where did those leading spaces come from? The header line is
definitely not on board with that, and I think those spaces are
contributing to the lines being too long for the window. I think
possibly the code is also adding a space that shouldn't be there
at the end of the lines, because it prints lines that wrap around
if I \pset columns to either 79 or 80 in an 80-column window, so
the accounting is off by 2 someplace.

Also, this code looks quite broken:

width = dwidth + swidth + hwidth;
if ((output_columns > 0) && (width > output_columns))
{
dwidth = output_columns - hwidth - swidth;
width = output_columns;
}

What happens if output_columns is less than hwidth + swidth? The code
goes crazy is what happens, because all of these are unsigned ints and so
wraparound leads to setting dwidth to something approaching 4 billion.
Try the same example after "\pset columns 10". I don't necessarily expect
it to produce beautiful output, but I do expect it to not lock up.

regards, tom lane