Emre Hasegeli <e...@hasegeli.com> writes:
> Pavel Stehule <pavel.steh...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
