Home > mailing lists

Thread: Problem with displaying "wide" tables in psql

Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

03 December 2013, 22:06:18

Hi.

Psql definitely have a problem with displaying "wide" tables.

Even in expanded mode, they look horrible.

So I tried to solve this problem.

Before the patch:

postgres=# \x 1
Expanded display (expanded) is on.
postgres=# \pset border 2
Border style (border) is 2.
postgres=# select * from pg_stats;

+-[ RECORD 1 ]-----------+------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
----------------------------------------------------------+
| schemaname | pg_catalog

|
| tablename | pg_proc
...

and after:

+-[ RECORD 1 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | proname |
| inherited | f |
| null_frac | 0 |
| avg_width | 64 |
| n_distinct | -0.823159 |
| most_common_vals | {max,min,overlaps,has_column_privilege,date_part,int4
,length,substring,sum,to_char,avg,int8,numeric,abs,generate_series,has_any_colum
n_privilege,has_database_privilege,has_foreign_data_wrapper_privilege,has_functi
on_privilege,has_language_privilege,has_schema_privilege,has_sequence_privilege,
has_server_privilege,has_table_privilege,has_tablespace_privilege,has_type_privi
lege,overlay,pg_has_role,point,stddev,stddev_pop,stddev_samp,text,time,timestamp
tz,timezone,var_pop,var_samp,variance,age,float4,float8,int2,isfinite,pg_get_vie
wdef,timestamp,bit_and,bit_or,mod,octet_length,polygon,substr,trunc,ts_headline,
ts_rank,ts_rank_cd,area,bit,bit_length,box,bpchar,btrim,circle,date,date_trunc,i
nterval,ishorizontal,isvertical,lag,lead,like,log,money,name,notlike,position,ro
und,timetz,to_ascii,abbrev,abstime,array_fill,array_to_json,array_to_string,ceil
,ceiling,center,char,char_length,character_length,count,daterange,enum_range,exp
,floor,format,generate_subscripts,get_bit,gin_extract_tsquery,gin_extract_tsvect
or} |
...
| correlation | 0.254019 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 2 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | pronamespace |
| inherited | f |
| null_frac | 0 |
| avg_width | 4 |
| n_distinct | 2 |
| most_common_vals | {11,12410} |
| most_common_freqs | {0.995274,0.00472627} |
| histogram_bounds | |
| correlation | 1 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 3 ]-----------+-----------------------------------------------------+

Best regards,

Sergey Muraviov

Attachment

fix_psql_print_aligned_vertical.patch

Re: Problem with displaying "wide" tables in psql

From

Pavel Stehule

Date:

03 December 2013, 22:19:44

Hello

do you know a pager less trick

http://merlinmoncure.blogspot.cz/2007/10/better-psql-with-less.html

Regards

Pavel Stehule

2013/12/3 Sergey Muraviov <sergey.k.muraviov@gmail.com>

Hi.

Psql definitely have a problem with displaying "wide" tables.
Even in expanded mode, they look horrible.
So I tried to solve this problem.

Before the patch:
postgres=# \x 1
Expanded display (expanded) is on.
postgres=# \pset border 2
Border style (border) is 2.
postgres=# select * from pg_stats;

+-[ RECORD 1 ]-----------+------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
----------------------------------------------------------+
| schemaname | pg_catalog

|
| tablename | pg_proc
...

and after:

+-[ RECORD 1 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | proname |
| inherited | f |
| null_frac | 0 |
| avg_width | 64 |
| n_distinct | -0.823159 |
| most_common_vals | {max,min,overlaps,has_column_privilege,date_part,int4
,length,substring,sum,to_char,avg,int8,numeric,abs,generate_series,has_any_colum
n_privilege,has_database_privilege,has_foreign_data_wrapper_privilege,has_functi
on_privilege,has_language_privilege,has_schema_privilege,has_sequence_privilege,
has_server_privilege,has_table_privilege,has_tablespace_privilege,has_type_privi
lege,overlay,pg_has_role,point,stddev,stddev_pop,stddev_samp,text,time,timestamp
tz,timezone,var_pop,var_samp,variance,age,float4,float8,int2,isfinite,pg_get_vie
wdef,timestamp,bit_and,bit_or,mod,octet_length,polygon,substr,trunc,ts_headline,
ts_rank,ts_rank_cd,area,bit,bit_length,box,bpchar,btrim,circle,date,date_trunc,i
nterval,ishorizontal,isvertical,lag,lead,like,log,money,name,notlike,position,ro
und,timetz,to_ascii,abbrev,abstime,array_fill,array_to_json,array_to_string,ceil
,ceiling,center,char,char_length,character_length,count,daterange,enum_range,exp
,floor,format,generate_subscripts,get_bit,gin_extract_tsquery,gin_extract_tsvect
or} |
...
| correlation | 0.254019 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 2 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | pronamespace |
| inherited | f |
| null_frac | 0 |
| avg_width | 4 |
| n_distinct | 2 |
| most_common_vals | {11,12410} |
| most_common_freqs | {0.995274,0.00472627} |
| histogram_bounds | |
| correlation | 1 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 3 ]-----------+-----------------------------------------------------+

Best regards,
Sergey Muraviov

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

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

04 December 2013, 10:20:58

Thank you for this trick.

It would be nice if this trick was documented.

However, with the pager I can't see wide value on one screen, select and copy it entirely.

And I have to press many keys to find the necessary part of the value.

There is no such problems with the patch.

2013/12/3 Pavel Stehule <pavel.stehule@gmail.com>

Hello

do you know a pager less trick

http://merlinmoncure.blogspot.cz/2007/10/better-psql-with-less.html

Regards

Pavel Stehule

2013/12/3 Sergey Muraviov <sergey.k.muraviov@gmail.com>
Hi.

Psql definitely have a problem with displaying "wide" tables.
Even in expanded mode, they look horrible.
So I tried to solve this problem.

Before the patch:
postgres=# \x 1
Expanded display (expanded) is on.
postgres=# \pset border 2
Border style (border) is 2.
postgres=# select * from pg_stats;

+-[ RECORD 1 ]-----------+------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
----------------------------------------------------------+
| schemaname | pg_catalog

|
| tablename | pg_proc
...

and after:

+-[ RECORD 1 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | proname |
| inherited | f |
| null_frac | 0 |
| avg_width | 64 |
| n_distinct | -0.823159 |
| most_common_vals | {max,min,overlaps,has_column_privilege,date_part,int4
,length,substring,sum,to_char,avg,int8,numeric,abs,generate_series,has_any_colum
n_privilege,has_database_privilege,has_foreign_data_wrapper_privilege,has_functi
on_privilege,has_language_privilege,has_schema_privilege,has_sequence_privilege,
has_server_privilege,has_table_privilege,has_tablespace_privilege,has_type_privi
lege,overlay,pg_has_role,point,stddev,stddev_pop,stddev_samp,text,time,timestamp
tz,timezone,var_pop,var_samp,variance,age,float4,float8,int2,isfinite,pg_get_vie
wdef,timestamp,bit_and,bit_or,mod,octet_length,polygon,substr,trunc,ts_headline,
ts_rank,ts_rank_cd,area,bit,bit_length,box,bpchar,btrim,circle,date,date_trunc,i
nterval,ishorizontal,isvertical,lag,lead,like,log,money,name,notlike,position,ro
und,timetz,to_ascii,abbrev,abstime,array_fill,array_to_json,array_to_string,ceil
,ceiling,center,char,char_length,character_length,count,daterange,enum_range,exp
,floor,format,generate_subscripts,get_bit,gin_extract_tsquery,gin_extract_tsvect
or} |
...
| correlation | 0.254019 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 2 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | pronamespace |
| inherited | f |
| null_frac | 0 |
| avg_width | 4 |
| n_distinct | 2 |
| most_common_vals | {11,12410} |
| most_common_freqs | {0.995274,0.00472627} |
| histogram_bounds | |
| correlation | 1 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 3 ]-----------+-----------------------------------------------------+

Best regards,
Sergey Muraviov

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

Best regards,

Sergey Muraviov

Re: Problem with displaying "wide" tables in psql

From

Alexander Korotkov

Date:

04 December 2013, 14:56:49

On Wed, Dec 4, 2013 at 11:20 AM, Sergey Muraviov <sergey.k.muraviov@gmail.com> wrote:

Thank you for this trick.
It would be nice if this trick was documented.

However, with the pager I can't see wide value on one screen, select and copy it entirely.
And I have to press many keys to find the necessary part of the value.
There is no such problems with the patch.

I think the solution is to provide proposed behaviour as an option.

------
With best regards,
Alexander Korotkov.

Re: Problem with displaying "wide" tables in psql

From

Pavel Stehule

Date:

04 December 2013, 17:55:35

Hello

postgres=# \pset format wrapped
Output format (format) is wrapped.
postgres=# select 'afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf';
?column?
---------------------------------------------------------------------------------------------------------------------
afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf a.
.sdf sad f sadf sad fadsf
(1 row)

It works as expected

but it is not supported for row view. So any fix of this mode should be nice

Regards

Pavel

2013/12/4 Sergey Muraviov <sergey.k.muraviov@gmail.com>

Thank you for this trick.
It would be nice if this trick was documented.

However, with the pager I can't see wide value on one screen, select and copy it entirely.
And I have to press many keys to find the necessary part of the value.
There is no such problems with the patch.

2013/12/3 Pavel Stehule <pavel.stehule@gmail.com>
Hello

do you know a pager less trick

http://merlinmoncure.blogspot.cz/2007/10/better-psql-with-less.html

Regards

Pavel Stehule

2013/12/3 Sergey Muraviov <sergey.k.muraviov@gmail.com>
Hi.

Psql definitely have a problem with displaying "wide" tables.
Even in expanded mode, they look horrible.
So I tried to solve this problem.

Before the patch:
postgres=# \x 1
Expanded display (expanded) is on.
postgres=# \pset border 2
Border style (border) is 2.
postgres=# select * from pg_stats;

+-[ RECORD 1 ]-----------+------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
----------------------------------------------------------+
| schemaname | pg_catalog

|
| tablename | pg_proc
...

and after:

+-[ RECORD 1 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | proname |
| inherited | f |
| null_frac | 0 |
| avg_width | 64 |
| n_distinct | -0.823159 |
| most_common_vals | {max,min,overlaps,has_column_privilege,date_part,int4
,length,substring,sum,to_char,avg,int8,numeric,abs,generate_series,has_any_colum
n_privilege,has_database_privilege,has_foreign_data_wrapper_privilege,has_functi
on_privilege,has_language_privilege,has_schema_privilege,has_sequence_privilege,
has_server_privilege,has_table_privilege,has_tablespace_privilege,has_type_privi
lege,overlay,pg_has_role,point,stddev,stddev_pop,stddev_samp,text,time,timestamp
tz,timezone,var_pop,var_samp,variance,age,float4,float8,int2,isfinite,pg_get_vie
wdef,timestamp,bit_and,bit_or,mod,octet_length,polygon,substr,trunc,ts_headline,
ts_rank,ts_rank_cd,area,bit,bit_length,box,bpchar,btrim,circle,date,date_trunc,i
nterval,ishorizontal,isvertical,lag,lead,like,log,money,name,notlike,position,ro
und,timetz,to_ascii,abbrev,abstime,array_fill,array_to_json,array_to_string,ceil
,ceiling,center,char,char_length,character_length,count,daterange,enum_range,exp
,floor,format,generate_subscripts,get_bit,gin_extract_tsquery,gin_extract_tsvect
or} |
...
| correlation | 0.254019 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 2 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | pronamespace |
| inherited | f |
| null_frac | 0 |
| avg_width | 4 |
| n_distinct | 2 |
| most_common_vals | {11,12410} |
| most_common_freqs | {0.995274,0.00472627} |
| histogram_bounds | |
| correlation | 1 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 3 ]-----------+-----------------------------------------------------+

Best regards,
Sergey Muraviov

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

--
Best regards,
Sergey Muraviov

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

05 December 2013, 09:09:56

And my patch affects the row view only.

postgres=# \x 1

postgres=# create table wide_table (value text);

postgres=# insert into wide_table values ('afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf');

postgres=# insert into wide_table values ('afadsafasd fasdf asdfasd');

postgres=# select * from wide_table;

-[ RECORD 1 ]-------------------------------------------------------------------

-------------------------------------------------------------------

value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsad

fasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf

-[ RECORD 2 ]-------------------------------------------------------------------

-------------------------------------------------------------------

value | afadsafasd fasdf

If we add a new column to this table and put the border on, we can see that all values in the table have the same width.

postgres=# alter table wide_table add column id integer;

postgres=# \pset border 2

postgres=# select * from wide_table;

+-[ RECORD 1 ]------------------------------------------------------------------

----------------------------------------------------------------------+

| value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfs

adfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf |

| id |

+-[ RECORD 2 ]------------------------------------------------------------------

----------------------------------------------------------------------+

| value | afadsafasd fasdf asdfasd

| id |

+-------+-----------------------------------------------------------------------

----------------------------------------------------------------------+

My patch tries to solve these problems:

-[ RECORD 1 ]-------------------------------------------------------------------

value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsad

fasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf

-[ RECORD 2 ]-------------------------------------------------------------------

value | afadsafasd fasdf asdfasd

and

+-[ RECORD 1 ]-----------------------------------------------------------------+

| value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfs

adfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf |

| id | |

+-[ RECORD 2 ]-----------------------------------------------------------------+

| value | afadsafasd fasdf asdfasd |

| id | |

+-------+----------------------------------------------------------------------+

Regards

2013/12/4 Pavel Stehule <pavel.stehule@gmail.com>

Hello

postgres=# \pset format wrapped
Output format (format) is wrapped.
postgres=# select 'afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf';
?column?
---------------------------------------------------------------------------------------------------------------------
afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf a.
.sdf sad f sadf sad fadsf
(1 row)

It works as expected

but it is not supported for row view. So any fix of this mode should be nice

Regards

Pavel

2013/12/4 Sergey Muraviov <sergey.k.muraviov@gmail.com>
Thank you for this trick.
It would be nice if this trick was documented.

However, with the pager I can't see wide value on one screen, select and copy it entirely.
And I have to press many keys to find the necessary part of the value.
There is no such problems with the patch.

2013/12/3 Pavel Stehule <pavel.stehule@gmail.com>
Hello

do you know a pager less trick

http://merlinmoncure.blogspot.cz/2007/10/better-psql-with-less.html

Regards

Pavel Stehule

2013/12/3 Sergey Muraviov <sergey.k.muraviov@gmail.com>
Hi.

Psql definitely have a problem with displaying "wide" tables.
Even in expanded mode, they look horrible.
So I tried to solve this problem.

Before the patch:
postgres=# \x 1
Expanded display (expanded) is on.
postgres=# \pset border 2
Border style (border) is 2.
postgres=# select * from pg_stats;

+-[ RECORD 1 ]-----------+------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
----------------------------------------------------------+
| schemaname | pg_catalog

|
| tablename | pg_proc
...

and after:

+-[ RECORD 1 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | proname |
| inherited | f |
| null_frac | 0 |
| avg_width | 64 |
| n_distinct | -0.823159 |
| most_common_vals | {max,min,overlaps,has_column_privilege,date_part,int4
,length,substring,sum,to_char,avg,int8,numeric,abs,generate_series,has_any_colum
n_privilege,has_database_privilege,has_foreign_data_wrapper_privilege,has_functi
on_privilege,has_language_privilege,has_schema_privilege,has_sequence_privilege,
has_server_privilege,has_table_privilege,has_tablespace_privilege,has_type_privi
lege,overlay,pg_has_role,point,stddev,stddev_pop,stddev_samp,text,time,timestamp
tz,timezone,var_pop,var_samp,variance,age,float4,float8,int2,isfinite,pg_get_vie
wdef,timestamp,bit_and,bit_or,mod,octet_length,polygon,substr,trunc,ts_headline,
ts_rank,ts_rank_cd,area,bit,bit_length,box,bpchar,btrim,circle,date,date_trunc,i
nterval,ishorizontal,isvertical,lag,lead,like,log,money,name,notlike,position,ro
und,timetz,to_ascii,abbrev,abstime,array_fill,array_to_json,array_to_string,ceil
,ceiling,center,char,char_length,character_length,count,daterange,enum_range,exp
,floor,format,generate_subscripts,get_bit,gin_extract_tsquery,gin_extract_tsvect
or} |
...
| correlation | 0.254019 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 2 ]-----------+-----------------------------------------------------+
| schemaname | pg_catalog |
| tablename | pg_proc |
| attname | pronamespace |
| inherited | f |
| null_frac | 0 |
| avg_width | 4 |
| n_distinct | 2 |
| most_common_vals | {11,12410} |
| most_common_freqs | {0.995274,0.00472627} |
| histogram_bounds | |
| correlation | 1 |
| most_common_elems | |
| most_common_elem_freqs | |
| elem_count_histogram | |
+-[ RECORD 3 ]-----------+-----------------------------------------------------+

Best regards,
Sergey Muraviov

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

--
Best regards,
Sergey Muraviov

Best regards,

Sergey Muraviov

Re: Problem with displaying "wide" tables in psql

From

Robert Haas

Date:

05 December 2013, 21:36:32

On Thu, Dec 5, 2013 at 1:09 AM, Sergey Muraviov
<sergey.k.muraviov@gmail.com> wrote:
> And my patch affects the row view only.

To help us avoid forgetting about this patch, please add it here:

https://commitfest.postgresql.org/action/commitfest_view/open

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Problem with displaying "wide" tables in psql

From

Jeff Janes

Date:

10 December 2013, 02:28:43

On Mon, Dec 2, 2013 at 10:45 PM, Sergey Muraviov <sergey.k.muraviov@gmail.com> wrote:

Hi.

Psql definitely have a problem with displaying "wide" tables.
Even in expanded mode, they look horrible.
So I tried to solve this problem.

I get compiler warnings:

print.c: In function 'print_aligned_vertical':

print.c:1238: warning: ISO C90 forbids mixed declarations and code

print.c: In function 'print_aligned_vertical':

print.c:1238: warning: ISO C90 forbids mixed declarations and code

But I really like this and am already benefiting from it. No point in having the string of hyphens between every record wrap to be 30 lines long just because one field somewhere down the list does so. And configuring the pager isn't much of a solution because the pager doesn't know that the hyphens are semantically different than the other stuff getting thrown at it.

Cheers,

Jeff

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

11 December 2013, 20:43:17

Hi.

I've improved the patch.

It works in expanded mode when either format option is set to wrapped (\pset format wrapped), or we have no pager, or pager doesn't chop long lines (so you can still use the trick).

Target output width is taken from either columns option (\pset columns 70), or environment variable $COLUMNS, or terminal size.

And it's also compatible with any border style (\pset border 0|1|2).

Here are some examples:

postgres=# \x 1

postgres=# \pset format wrapped

postgres=# \pset border 0

postgres=# select * from wide_table;

* Record 1

value afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df sadfsadfa

sd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf

* Record 2

value afadsafasd fasdf asdfasd

postgres=# \pset border 1

postgres=# \pset columns 70

postgres=# select * from wide_table;

-[ RECORD 1 ]---------------------------------------------------------

value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa

| df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f

| sadf sad fadsf

-[ RECORD 2 ]---------------------------------------------------------

value | afadsafasd fasdf asdfasd

postgres=# \pset border 2

postgres=# \pset columns 60

postgres=# select * from wide_table;

+-[ RECORD 1 ]---------------------------------------------+

| value | afadsafasd fasdf asdfasd fsad fas df sadf sad f |

| | sadf sadf sa df sadfsadfasd fsad fsa df sadf as |

| | d fa sfd sadfsadf asdf sad f sadf sad fadsf |

+-[ RECORD 2 ]---------------------------------------------+

| value | afadsafasd fasdf asdfasd |

+-------+--------------------------------------------------+

Regards,

Sergey

2013/12/10 Jeff Janes <jeff.janes@gmail.com>

On Mon, Dec 2, 2013 at 10:45 PM, Sergey Muraviov <sergey.k.muraviov@gmail.com> wrote:
Hi.

Psql definitely have a problem with displaying "wide" tables.
Even in expanded mode, they look horrible.
So I tried to solve this problem.

I get compiler warnings:

print.c: In function 'print_aligned_vertical':
print.c:1238: warning: ISO C90 forbids mixed declarations and code
print.c: In function 'print_aligned_vertical':
print.c:1238: warning: ISO C90 forbids mixed declarations and code

But I really like this and am already benefiting from it. No point in having the string of hyphens between every record wrap to be 30 lines long just because one field somewhere down the list does so. And configuring the pager isn't much of a solution because the pager doesn't know that the hyphens are semantically different than the other stuff getting thrown at it.

Cheers,

Jeff

Best regards,

Sergey Muraviov

Attachment

fix_psql_print_aligned_vertical_v2.patch

Re: Problem with displaying "wide" tables in psql

From

Sameer Thakur

Date:

18 December 2013, 09:43:37

On Wed, Dec 11, 2013 at 11:13 PM, Sergey Muraviov
<sergey.k.muraviov@gmail.com> wrote:
> Hi.
>
> I've improved the patch.
> It works in expanded mode when either format option is set to wrapped (\pset
> format wrapped), or we have no pager, or pager doesn't chop long lines (so
> you can still use the trick).
> Target output width is taken from either columns option (\pset columns 70),
> or environment variable $COLUMNS, or terminal size.
> And it's also compatible with any border style (\pset border 0|1|2).
>
> Here are some examples:
>
> postgres=# \x 1
> postgres=# \pset format wrapped
> postgres=# \pset border 0
> postgres=# select * from wide_table;
> * Record 1
> value afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf  sadf sa df
> sadfsadfa
>       sd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf
> * Record 2
> value afadsafasd fasdf asdfasd
>
> postgres=# \pset border 1
> postgres=# \pset columns 70
> postgres=# select * from wide_table;
> -[ RECORD 1 ]---------------------------------------------------------
> value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf  sadf sa
>       | df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f
>       |  sadf sad fadsf
> -[ RECORD 2 ]---------------------------------------------------------
> value | afadsafasd fasdf asdfasd
>
> postgres=# \pset border 2
> postgres=# \pset columns 60
> postgres=# select * from wide_table;
> +-[ RECORD 1 ]---------------------------------------------+
> | value | afadsafasd fasdf asdfasd fsad fas df sadf sad f  |
> |       | sadf  sadf sa df sadfsadfasd fsad fsa df sadf as |
> |       | d fa sfd sadfsadf asdf sad f sadf sad fadsf      |
> +-[ RECORD 2 ]---------------------------------------------+
> | value | afadsafasd fasdf asdfasd                         |
> +-------+--------------------------------------------------+
>
> Regards,
> Sergey
>

The patch  applies and compile cleanly. I tried the following
\pset format wrapped
\pset columns 70.
Not in expanded mode
select * from wide_table works fine.
select * from pg_stats has problems in viewing. Is it that pg_stats
can be viewed easily only in expanded mode i.e. if columns displayed
are wrapped then there is no way to view results in non expanded mode?
regards
Sameer

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

18 December 2013, 12:29:48

Hello

2013/12/18 Sameer Thakur <samthakur74@gmail.com>

On Wed, Dec 11, 2013 at 11:13 PM, Sergey Muraviov
<sergey.k.muraviov@gmail.com> wrote:
> Hi.
>
> I've improved the patch.
> It works in expanded mode when either format option is set to wrapped (\pset
> format wrapped), or we have no pager, or pager doesn't chop long lines (so
> you can still use the trick).
> Target output width is taken from either columns option (\pset columns 70),
> or environment variable $COLUMNS, or terminal size.
> And it's also compatible with any border style (\pset border 0|1|2).
>
> Here are some examples:
>
> postgres=# \x 1
> postgres=# \pset format wrapped
> postgres=# \pset border 0
> postgres=# select * from wide_table;
> * Record 1
> value afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df
> sadfsadfa
> sd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f sadf sad fadsf
> * Record 2
> value afadsafasd fasdf asdfasd
>
> postgres=# \pset border 1
> postgres=# \pset columns 70
> postgres=# select * from wide_table;
> -[ RECORD 1 ]---------------------------------------------------------
> value | afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa
> | df sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf asdf sad f
> | sadf sad fadsf
> -[ RECORD 2 ]---------------------------------------------------------
> value | afadsafasd fasdf asdfasd
>
> postgres=# \pset border 2
> postgres=# \pset columns 60
> postgres=# select * from wide_table;
> +-[ RECORD 1 ]---------------------------------------------+
> | value | afadsafasd fasdf asdfasd fsad fas df sadf sad f |
> | | sadf sadf sa df sadfsadfasd fsad fsa df sadf as |
> | | d fa sfd sadfsadf asdf sad f sadf sad fadsf |
> +-[ RECORD 2 ]---------------------------------------------+
> | value | afadsafasd fasdf asdfasd |
> +-------+--------------------------------------------------+
>
> Regards,
> Sergey
>

The patch applies and compile cleanly. I tried the following
\pset format wrapped
\pset columns 70.
Not in expanded mode
select * from wide_table works fine.
select * from pg_stats has problems in viewing. Is it that pg_stats
can be viewed easily only in expanded mode i.e. if columns displayed
are wrapped then there is no way to view results in non expanded mode?
regards
Sameer

The problem with non expanded mode is that all column headers have to be displayed on one line.

Otherwise, it is difficult to bind values to columns.

And I have no idea how to solve this problem.

Best regards,

Sergey Muraviov

Re: Problem with displaying "wide" tables in psql

From

Peter Eisentraut

Date:

24 December 2013, 18:35:48

Please fix this:

src/bin/psql/print.c:1269: trailing whitespace.
src/bin/psql/print.c:1351: trailing whitespace.
src/bin/psql/print.c:1359: trailing whitespace.
src/bin/psql/print.c:1364: trailing whitespace.
src/bin/psql/print.c:2263: trailing whitespace.

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

24 December 2013, 19:58:53

fixed

2013/12/24 Peter Eisentraut <peter_e@gmx.net>

Please fix this:

src/bin/psql/print.c:1269: trailing whitespace.
src/bin/psql/print.c:1351: trailing whitespace.
src/bin/psql/print.c:1359: trailing whitespace.
src/bin/psql/print.c:1364: trailing whitespace.
src/bin/psql/print.c:2263: trailing whitespace.

Best regards,

Sergey Muraviov

Attachment

fix_psql_print_aligned_vertical_v3.patch

Re: Problem with displaying "wide" tables in psql

From

Emre Hasegeli

Date:

15 February 2014, 19:08:46

Hi,

This is my review about 3th version of the patch. It is an useful
improvement in my opinion. It worked well on my environment.

2013-12-11 17:43:06, Sergey Muraviov <sergey.k.muraviov@gmail.com>:
> It works in expanded mode when either format option is set to wrapped
> (\pset format wrapped), or we have no pager, or pager doesn't chop long
> lines (so you can still use the trick).

I do not like this logic on the IsWrappingNeeded function. It does not
seems right to check the environment variables for less. It would be hard
to explain this behavior to the users. It is better to make this only
the behavior of the wrapped format in expanded mode, in my opinion.

>                               {
>                                       if (opt_border < 2)
>                                               fprintf(fout, "%s\n", dlineptr[line_count].ptr);
>                                       else
>                                               fprintf(fout, "%-s%*s %s\n", dlineptr[line_count].ptr,
>                                                               dwidth - dlineptr[line_count].width, "",
>                                                               dformat->rightvrule);
>                               }

Is it necessary to keep this old print line code? It seems to me the new
code works well on (dlineptr[line_count].width <= dwidth) condition.

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

16 February 2014, 19:37:48

Hi.

Thanks for your review.

2014-02-15 20:08 GMT+04:00 Emre Hasegeli <emre@hasegeli.com>:

Hi,

This is my review about 3th version of the patch. It is an useful
improvement in my opinion. It worked well on my environment.

2013-12-11 17:43:06, Sergey Muraviov <sergey.k.muraviov@gmail.com>:
> It works in expanded mode when either format option is set to wrapped
> (\pset format wrapped), or we have no pager, or pager doesn't chop long
> lines (so you can still use the trick).

I do not like this logic on the IsWrappingNeeded function. It does not
seems right to check the environment variables for less. It would be hard
to explain this behavior to the users. It is better to make this only
the behavior of the wrapped format in expanded mode, in my opinion.

You are right. This logic is too complicated.

New patch works with PRINT_WRAPPED option only.

> {
> if (opt_border < 2)
> fprintf(fout, "%s\n", dlineptr[line_count].ptr);
> else
> fprintf(fout, "%-s%*s %s\n", dlineptr[line_count].ptr,
> dwidth - dlineptr[line_count].width, "",
> dformat->rightvrule);
> }

Is it necessary to keep this old print line code? It seems to me the new
code works well on (dlineptr[line_count].width <= dwidth) condition.

New code doesn't work with empty strings but I've done minor optimization for this case.

Best regards,

Sergey Muraviov

Attachment

fix_psql_print_aligned_vertical_v4.patch

Re: Problem with displaying "wide" tables in psql

From

Emre Hasegeli

Date:

17 February 2014, 11:23:23

2014-02-16 18:37, Sergey Muraviov <sergey.k.muraviov@gmail.com>:

> New code doesn't work with empty strings but I've done minor optimization
> for this case.

It seems better now. I added some new lines and spaces, removed unnecessary
parentheses and marked it as "Ready for Committer".

Attachment

fix_psql_print_aligned_vertical_v5.patch

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

17 February 2014, 13:06:02

Thanks.

2014-02-17 12:22 GMT+04:00 Emre Hasegeli <emre@hasegeli.com>:

2014-02-16 18:37, Sergey Muraviov <sergey.k.muraviov@gmail.com>:

> New code doesn't work with empty strings but I've done minor optimization
> for this case.

It seems better now. I added some new lines and spaces, removed unnecessary
parentheses and marked it as "Ready for Committer".

Best regards,

Sergey Muraviov

Re: Problem with displaying "wide" tables in psql

From

Greg Stark

Date:

08 April 2014, 19:16:31

On Sat, Feb 15, 2014 at 11:08 AM, Emre Hasegeli <emre@hasegeli.com> wrote:
> This is my review about 3th version of the patch. It is an useful
> improvement in my opinion. It worked well on my environment.

I'm reviewing this patch.

One thing to comment:

With no doc changes and no regression tests I was halfway inclined to
just reject it out of hand. To be fair there were no regression tests
for wrapped output prior to the patch but still I would have wanted to
see them added. We often pare down regression tests when committing
patches but it's easier to pare them down than write new ones and it
helps show the author's intention.

In this case I'm inclined to expand the regression tests. We've had
bugs in these formatting functions before and at least I find it hard
to touch code like this with any confidence that I'm not breaking
things. Formatting code ends up being pretty spaghetti-like easily and
there are lots of cases so it's easy to unintentionally break cases
you didn't realize you were touching.

In addition there are several cases of logic that looks like this:

if (x) ..
else  {    if (y)      ...    else      ...  }

I know there are other opinions on this but I find this logic very
difficut to follow. It's almost always clearer to refactor the
branches into a flat if / else if / else if /.../ else form. Even if
it results in some duplication of code (typically there's some trivial
bit of code outside the second "if")  it's easy to quickly see whether
all the cases are handled and understand whether any of the cases have
forgotten any steps.

-- 
greg

Re: Problem with displaying "wide" tables in psql

From

Andres Freund

Date:

08 April 2014, 19:19:11

On 2014-04-08 12:15:47 -0400, Greg Stark wrote:
> With no doc changes and no regression tests I was halfway inclined to
> just reject it out of hand. To be fair there were no regression tests
> for wrapped output prior to the patch but still I would have wanted to
> see them added. We often pare down regression tests when committing
> patches but it's easier to pare them down than write new ones and it
> helps show the author's intention.

I don't think this is easily testable that way - doesn't it rely on
determining the width of the terminal? Which you won't have when started
from pg_regress?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services

Re: Problem with displaying "wide" tables in psql

From

Greg Stark

Date:

08 April 2014, 19:27:52

On Tue, Apr 8, 2014 at 12:19 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> I don't think this is easily testable that way - doesn't it rely on
> determining the width of the terminal? Which you won't have when started
> from pg_regress?

There's a pset variable to set the target width so at least the
formatting code can be tested. It would be nice to have the ioctl at
least get called on the regression farm so we're sure we aren't doing
something unportable.

-- 
greg

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

09 April 2014, 09:32:14

Hi.

How can I pass or set the value of pset variable for an regression test?

The code with ioctl was copied from print_aligned_text function, which has a long history.

43ee2282 (Bruce Momjian 2008-05-16 16:59:05 +0000 680) if (ioctl(fileno(stdout), TIOCGWINSZ, &screen_size) != -1)

2014-04-08 20:27 GMT+04:00 Greg Stark <stark@mit.edu>:

On Tue, Apr 8, 2014 at 12:19 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> I don't think this is easily testable that way - doesn't it rely on
> determining the width of the terminal? Which you won't have when started
> from pg_regress?

There's a pset variable to set the target width so at least the
formatting code can be tested. It would be nice to have the ioctl at
least get called on the regression farm so we're sure we aren't doing
something unportable.

--
greg

Best regards,

Sergey Muraviov

Re: Problem with displaying "wide" tables in psql

From

Greg Stark

Date:

09 April 2014, 21:02:26

> How can I pass or set the value of pset variable for an regression test?

I just wrote some tests using \pset columns to control the output.

Having figured out what the point of the patch is I'm pretty happy
with the functionality. It definitely is something I would appreciate
having.

One thing I noticed is that it's not using the formatting characters
to indicate newlines and wrapping. I'm trying to add that myself but
it's taking me a bit to figure out what's going on in the formatting
code. I do have a feeling this is all rearranging the deck chairs on
an obsolete technology and this should all be replaced with a web ui.

Re: Problem with displaying "wide" tables in psql

From

Greg Stark

Date:

10 April 2014, 17:46:13

Ok, So I've hacked on this a bit. Below is a test case showing the
problems I've found.

1) It isn't using the "newline" and "wrap" indicators or dividing lines.

2) The header is not being displayed properly when it contains a newline.

I can hack in the newline and wrap indicators but the header
formatting requires reworking the logic a bit. The header and data
need to be stepped through in parallel rather than having a loop to
handle the wrapping within the handling of a single line. I don't
really have time for that today but if you can get to it that would be
fine,

Attachment

psql-wrapping-tests.txt

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

10 April 2014, 23:14:17

Hi.

Thanks for your tests.

I've fixed problem with headers, but got new one with data.

I'll try to solve it tomorrow.

2014-04-10 18:45 GMT+04:00 Greg Stark <stark@mit.edu>:

Ok, So I've hacked on this a bit. Below is a test case showing the
problems I've found.

1) It isn't using the "newline" and "wrap" indicators or dividing lines.

2) The header is not being displayed properly when it contains a newline.

I can hack in the newline and wrap indicators but the header
formatting requires reworking the logic a bit. The header and data
need to be stepped through in parallel rather than having a loop to
handle the wrapping within the handling of a single line. I don't
really have time for that today but if you can get to it that would be
fine,

Best regards,

Sergey Muraviov

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

11 April 2014, 10:13:49

Hi.

I've done some corrections for printing "newline" and "wrap" indicators.

Please review the attached patch.

2014-04-11 0:14 GMT+04:00 Sergey Muraviov <sergey.k.muraviov@gmail.com>:

Hi.

Thanks for your tests.

I've fixed problem with headers, but got new one with data.
I'll try to solve it tomorrow.

2014-04-10 18:45 GMT+04:00 Greg Stark <stark@mit.edu>:

Ok, So I've hacked on this a bit. Below is a test case showing the
problems I've found.

1) It isn't using the "newline" and "wrap" indicators or dividing lines.

2) The header is not being displayed properly when it contains a newline.

I can hack in the newline and wrap indicators but the header
formatting requires reworking the logic a bit. The header and data
need to be stepped through in parallel rather than having a loop to
handle the wrapping within the handling of a single line. I don't
really have time for that today but if you can get to it that would be
fine,

--
Best regards,
Sergey Muraviov

Best regards,

Sergey Muraviov

Attachment

fix_psql_print_aligned_vertical_v6.patch

Re: Problem with displaying "wide" tables in psql

From

Greg Stark

Date:

11 April 2014, 18:10:56

Looks good.

It's still not doing the old-ascii column dividers but to be honest
I'm not sure what the intended behaviour of old-ascii is. I've noticed
old-ascii only displays the line markers for dividing lines, not the
final one. That seems pretty useless and maybe it's why we switched to
the new "ascii" mode, I don't recall.

This is the way old-ascii displays when two columns are wrapping -- it
seems pretty confused to me. The headers are displaying newline
markers from the ascii style instead of : indicators in the dividing
line. The : and ; markers are only displayed for the first column, not
the second one.

Maybe since the : and ; markers aren't shown for the final column that
means the expanded mode doesn't have to do anything since the column
is only ever the final column.


+--------------------+-----------------+
|         x          |        x        |
|+        y          |+       y        |
|+        z          |+       z        |
+--------------------+-----------------+
| x                  | xxxxxxxxxxxxxxx |
| xx                 ; xxxx            |
| xxx                : xxxxxxxxxxxxxxx |
| xxxx               ; xxx             |
| xxxxx              : xxxxxxxxxxxxxxx |
| xxxxxx             ; xx              |
| xxxxxxx            : xxxxxxxxxxxxxxx |
| xxxxxxxx           ; x               |
| xxxxxxxxx          : xxxxxxxxxxxxxxx |
| xxxxxxxxxx         : xxxxxxxxxxxxxx  |
| xxxxxxxxxxx        : xxxxxxxxxxxxx   |
| xxxxxxxxxxxx       : xxxxxxxxxxxx    |
| xxxxxxxxxxxxx      : xxxxxxxxxxx     |
| xxxxxxxxxxxxxx     : xxxxxxxxxx      |
| xxxxxxxxxxxxxxx    : xxxxxxxxx       |
| xxxxxxxxxxxxxxxx   : xxxxxxxx        |
| xxxxxxxxxxxxxxxxx  : xxxxxxx         |
| xxxxxxxxxxxxxxxxxx : xxxxxx          |
| xxxxxxxxxxxxxxxxxx : xxxxx           |
| x                  : xxxx            |
| xxxxxxxxxxxxxxxxxx : xxx             |
| xx                 : xx              |
| xxxxxxxxxxxxxxxxxx : x               |
| xxx                :                 |
| xxxxxxxxxxxxxxxxxx :                 |
| xxxx               :                 |
| xxxxxxxxxxxxxxxxxx :                 |
| xxxxx              :                 |
| xxxxxxxxxxxxxxxxxx :                 |
| xxxxxx                               |
| xxxxxxxxxxxxxxxxxx                   |
| xxxxxxx                              |
+--------------------+-----------------+

Attachment

printc-debug-3.txt

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

11 April 2014, 20:03:32

I hope that I realized old-ascii logic correctly.

2014-04-11 19:10 GMT+04:00 Greg Stark <stark@mit.edu>:

Looks good.

It's still not doing the old-ascii column dividers but to be honest
I'm not sure what the intended behaviour of old-ascii is. I've noticed
old-ascii only displays the line markers for dividing lines, not the
final one. That seems pretty useless and maybe it's why we switched to
the new "ascii" mode, I don't recall.

This is the way old-ascii displays when two columns are wrapping -- it
seems pretty confused to me. The headers are displaying newline
markers from the ascii style instead of : indicators in the dividing
line. The : and ; markers are only displayed for the first column, not
the second one.

Maybe since the : and ; markers aren't shown for the final column that
means the expanded mode doesn't have to do anything since the column
is only ever the final column.

+--------------------+-----------------+
| x | x |
|+ y |+ y |
|+ z |+ z |
+--------------------+-----------------+
| x | xxxxxxxxxxxxxxx |
| xx ; xxxx |
| xxx : xxxxxxxxxxxxxxx |
| xxxx ; xxx |
| xxxxx : xxxxxxxxxxxxxxx |
| xxxxxx ; xx |
| xxxxxxx : xxxxxxxxxxxxxxx |
| xxxxxxxx ; x |
| xxxxxxxxx : xxxxxxxxxxxxxxx |
| xxxxxxxxxx : xxxxxxxxxxxxxx |
| xxxxxxxxxxx : xxxxxxxxxxxxx |
| xxxxxxxxxxxx : xxxxxxxxxxxx |
| xxxxxxxxxxxxx : xxxxxxxxxxx |
| xxxxxxxxxxxxxx : xxxxxxxxxx |
| xxxxxxxxxxxxxxx : xxxxxxxxx |
| xxxxxxxxxxxxxxxx : xxxxxxxx |
| xxxxxxxxxxxxxxxxx : xxxxxxx |
| xxxxxxxxxxxxxxxxxx : xxxxxx |
| xxxxxxxxxxxxxxxxxx : xxxxx |
| x : xxxx |
| xxxxxxxxxxxxxxxxxx : xxx |
| xx : xx |
| xxxxxxxxxxxxxxxxxx : x |
| xxx : |
| xxxxxxxxxxxxxxxxxx : |
| xxxx : |
| xxxxxxxxxxxxxxxxxx : |
| xxxxx : |
| xxxxxxxxxxxxxxxxxx : |
| xxxxxx |
| xxxxxxxxxxxxxxxxxx |
| xxxxxxx |
+--------------------+-----------------+

Best regards,

Sergey Muraviov

Attachment

fix_psql_print_aligned_vertical_v7.patch

Re: Problem with displaying "wide" tables in psql

From

Alvaro Herrera

Date:

11 April 2014, 20:58:49

Sergey Muraviov wrote:
> I hope that I realized old-ascii logic correctly.

I don't know what you changed here, but I don't think we need to
preserve old-ascii behavior in the new code, in any way.  If you're
mimicking something obsolete and the end result of the new feature is
not great, perhaps that should be rethought.

Can you please provide sample output for the previous version compared
to this new version?  What changed?


-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

11 April 2014, 22:07:59

There were no support for wrapping and old-ascii line style in expanded mode at all.

But now they are.

2014-04-11 21:58 GMT+04:00 Alvaro Herrera <alvherre@2ndquadrant.com>:

Sergey Muraviov wrote:
> I hope that I realized old-ascii logic correctly.

I don't know what you changed here, but I don't think we need to
preserve old-ascii behavior in the new code, in any way. If you're
mimicking something obsolete and the end result of the new feature is
not great, perhaps that should be rethought.

Can you please provide sample output for the previous version compared
to this new version? What changed?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Best regards,

Sergey Muraviov

Attachment

output.txt

Re: Problem with displaying "wide" tables in psql

From

Greg Stark

Date:

11 April 2014, 23:47:26

<p dir="ltr">Yeah, I think I agree. I'm pretty happy to commit it without old-ascii doing anything special.<p
dir="ltr">Itlooks to me like old-ascii just isn't very useful for a single column output (like expanded mode is
implicitly).Maybe that needs to be fixed but then it needs to be fixed for non expanded mode as well.<p dir="ltr">I
don'tthink this new output is very useful dive it just displays the old-ascii info for the header cells. The header
cellsnever wrap and often have a lot of empty lines so it just looks like noise.<p dir="ltr">I do think the earlier
changetoday was important. It looks great now with the wrap and newline indicators in ascii and Unicode mode. <p
dir="ltr">FwiwI've switched my .psqlrc to use Unicode and wrapped=auto be default. It makes psql way more usable. It's
evenbetter than my old technique of running it in Emacs and scrolling left and right.<p dir="ltr">I'll take a look at
itthis evening and will add regression tests (and probably more comments too!) and commit. I want to try adding Unicode
regressiontests but I'm not sure what the state of the art is for Unicode fallback behaviour on the build farm. I think
thereare some existing tests we can copy iirc.<br /><p dir="ltr">-- <br /> greg

Re: Problem with displaying "wide" tables in psql

From

Greg Stark

Date:

26 April 2014, 15:45:52

On Fri, Apr 11, 2014 at 9:47 PM, Greg Stark <stark@mit.edu> wrote:
> I'll take a look at it this evening and will add regression tests (and
> probably more comments too!) and commit.

Well that evening turned into this morning a week later. Thanks to
Emre who fixed the remaining problems.

I added a regression test that tests every combination of linestyle
and border and format. That makes it kind of long but it's fast to run
and this code is easy to break so I would prefer to have tests for the
next time someone tries to fix something in it.

I expect this regression test to fail on platforms that don't support
utf-8 client-side (I'm assuming we such things?). I don't have such a
platform here and I'm not sure how it would fail so I want to go ahead
and apply it and grab the output to add the alternate output when it
fails on the build-farm. Would that be ok?

--
greg

Attachment

fix_psql_print_aligned_vertical_v8.patch

Re: Problem with displaying "wide" tables in psql

From

Tom Lane

Date:

26 April 2014, 18:16:10

Greg Stark <stark@mit.edu> writes:
> I expect this regression test to fail on platforms that don't support
> utf-8 client-side (I'm assuming we such things?). I don't have such a
> platform here and I'm not sure how it would fail so I want to go ahead
> and apply it and grab the output to add the alternate output when it
> fails on the build-farm. Would that be ok?

Are you expecting to carry an alternate expected file for every possible
encoding choice?  That does not seem workable to me, and even if we could
do it the cost/benefit ratio would be pretty grim.  I think you should
drop the UTF8-dependent tests.

In other words: there are no encoding dependencies in the existing
standard regression tests.  This feature is not the place to start adding
them, and two weeks past feature freeze is not the time to start adding
them either.  We don't have time right now to shake out a whole new
set of platform dependencies in the regression tests.

If you feel these tests must be preserved someplace, you could add a
new regression test that isn't run by default, following in the
footsteps of collate.linux.utf8.
        regards, tom lane

Re: Problem with displaying "wide" tables in psql

From

Greg Stark

Date:

26 April 2014, 19:13:07

<p dir="ltr">Not sure what other encodings you mean. Psql uses utf8 for the border and the test uses utf8 to test the
formatting.I was only anticipating an error on platforms where that didn't work.<p dir="ltr">I would lean towards
havingit but I'm fine following your judgement, especially given the timing.<br /><p dir="ltr">-- <br /> greg

Re: Problem with displaying "wide" tables in psql

From

Tom Lane

Date:

26 April 2014, 19:32:00

Greg Stark <stark@mit.edu> writes:
> Not sure what other encodings you mean. Psql uses utf8 for the border and
> the test uses utf8 to test the formatting. I was only anticipating an error
> on platforms where that didn't work.

Well, there are two likely misbehaviors if the regression test is being
run in some other encoding:

1. If it's a single-byte encoding, you probably won't get any bad-encoding
complaints, but the code will think the utf8 characters represent multiple
logical characters, resulting in (at least) spacing differences.  It's
possible that all single-byte encodings would act the same, but I'm not
sure.

2. If it's a multi-byte encoding different from utf8, you're almost
certainly going to get badly-encoded-data complaints, at different places
depending on the particular encoding.

I don't remember how many different multibyte encodings we support,
but I'm pretty sure we'd need a separate expected file for each one.
Plus at least one for the single-byters.

The real problem is that I don't have a lot of confidence that the
buildfarm would provide us with full coverage of all the encodings
that somebody might use in the field.  So we might not find out about
omissions or wrong expected-files until after we ship.

Anyway, the bottom line for me is that this test isn't worth that
much trouble.  I'm okay with putting it in as a separate test file
that we don't support running in non-utf8 encodings.
        regards, tom lane

Re: Problem with displaying "wide" tables in psql

From

Peter Eisentraut

Date:

29 April 2014, 04:52:17

Please fix this compiler warning.  I think it came from this patch.


print.c: In function ‘print_aligned_vertical’:
print.c:1354:10: error: pointer targets in passing argument 1 of ‘strlen_max_width’ differ in signedness
[-Werror=pointer-sign]        encoding);         ^ 
print.c:126:12: note: expected ‘unsigned char *’ but argument is of type ‘char *’static int strlen_max_width(unsigned
char*str, int *target_width, int encoding);           ^

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

29 April 2014, 06:37:59

fixed

2014-04-29 5:52 GMT+04:00 Peter Eisentraut <peter_e@gmx.net>:

Please fix this compiler warning. I think it came from this patch.

print.c: In function ‘print_aligned_vertical’:
print.c:1354:10: error: pointer targets in passing argument 1 of ‘strlen_max_width’ differ in signedness [-Werror=pointer-sign]
encoding);
^
print.c:126:12: note: expected ‘unsigned char *’ but argument is of type ‘char *’
static int strlen_max_width(unsigned char *str, int *target_width, int encoding);
^

Best regards,

Sergey Muraviov

Attachment

fix_psql_print_aligned_vertical_v12.patch

Re: Problem with displaying "wide" tables in psql

From

Michael Paquier

Date:

29 April 2014, 06:43:41

On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
<sergey.k.muraviov@gmail.com> wrote:
> 2014-04-29 5:52 GMT+04:00 Peter Eisentraut <peter_e@gmx.net>:
>
>> Please fix this compiler warning.  I think it came from this patch.
>> print.c: In function 'print_aligned_vertical':
>> print.c:1354:10: error: pointer targets in passing argument 1 of
>> 'strlen_max_width' differ in signedness [-Werror=pointer-sign]
>>           encoding);
>>           ^
>> print.c:126:12: note: expected 'unsigned char *' but argument is of type
>> 'char *'
>>  static int strlen_max_width(unsigned char *str, int *target_width, int
>> encoding);
>>             ^
> fixed
Your patch has been committed by Greg not so long ago, you should send
for this warning a patch rebased on the latest master branch commit :)
-- 
Michael

Re: Problem with displaying "wide" tables in psql

From

Sergey Muraviov

Date:

29 April 2014, 07:07:21

rebased

2014-04-29 7:43 GMT+04:00 Michael Paquier <michael.paquier@gmail.com>:

On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
<sergey.k.muraviov@gmail.com> wrote:
> 2014-04-29 5:52 GMT+04:00 Peter Eisentraut <peter_e@gmx.net>:
>
>> Please fix this compiler warning. I think it came from this patch.
>> print.c: In function 'print_aligned_vertical':
>> print.c:1354:10: error: pointer targets in passing argument 1 of
>> 'strlen_max_width' differ in signedness [-Werror=pointer-sign]
>> encoding);
>> ^
>> print.c:126:12: note: expected 'unsigned char *' but argument is of type
>> 'char *'
>> static int strlen_max_width(unsigned char *str, int *target_width, int
>> encoding);
>> ^
> fixed
Your patch has been committed by Greg not so long ago, you should send
for this warning a patch rebased on the latest master branch commit :)
--
Michael

Best regards,

Sergey Muraviov

Attachment

fix_psql_print_aligned_vertical_v13.patch

Re: Problem with displaying "wide" tables in psql

From

Greg Stark

Date:

29 April 2014, 14:42:09

On Tue, Apr 29, 2014 at 2:52 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> Please fix this compiler warning.  I think it came from this patch.


Oops, I fixed it in a previous version but didn't notice it had crept
back in in the back-and-forth. Will do.

-- 
greg