Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-29 Thread Greg Stark
On Tue, Apr 29, 2014 at 2:52 AM, Peter Eisentraut pete...@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


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-28 Thread Peter Eisentraut
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);
^




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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-28 Thread Michael Paquier
On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
sergey.k.murav...@gmail.com wrote:
 2014-04-29 5:52 GMT+04:00 Peter Eisentraut pete...@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


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-28 Thread Sergey Muraviov
rebased


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

 On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
 sergey.k.murav...@gmail.com wrote:
  2014-04-29 5:52 GMT+04:00 Peter Eisentraut pete...@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
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 0eb..b2f56a3 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1350,8 +1350,7 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 			{
 int swidth, twidth = hwidth + 1;
 fputs(hline? format-header_nl_left:  , fout);
-strlen_max_width((char *) hlineptr[hline].ptr, twidth,
- encoding);
+strlen_max_width(hlineptr[hline].ptr, twidth, encoding);
 fprintf(fout, %-s, hlineptr[hline].ptr);
 
 swidth = hwidth - twidth;

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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-26 Thread Tom Lane
Greg Stark st...@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


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-26 Thread Greg Stark
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.

I would lean towards having it but I'm fine following your judgement,
especially given the timing.

-- 
greg


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-26 Thread Tom Lane
Greg Stark st...@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


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-11 Thread Sergey Muraviov
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.murav...@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 st...@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
From 5e0f44994d04a81523920a78d3a35603e919170c Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Fri, 11 Apr 2014 11:03:41 +0400
Subject: [PATCH] Using newline and wrap indicators

---
 src/bin/psql/print.c | 130 +++
 1 file changed, 110 insertions(+), 20 deletions(-)

diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 79fc43e..6463162 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1234,13 +1234,56 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 			fprintf(fout, %s\n, cont-title);
 	}
 
+		if (cont-opt-format == PRINT_WRAPPED)
+	{
+		int output_columns = 0;
+
+		/*
+		 * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+		 */
+		if (cont-opt-columns  0)
+			output_columns = cont-opt-columns;
+		else
+		{
+			if (cont-opt-env_columns  0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+			else
+			{
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+	output_columns = screen_size.ws_col;
+			}
+#endif
+		}
+
+		output_columns -= hwidth;
+
+		if (opt_border == 0)
+			output_columns -= 1;
+		else
+		{
+			output_columns -= 3; /* -+- */
+
+			if (opt_border  1)
+output_columns -= 4; /* +--+ */
+		}
+
+		if (output_columns  0  dwidth  output_columns)
+			dwidth = output_columns;
+	}
+
 	/* print records */
 	for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
 	{
 		printTextRule pos;
-		int			line_count,
+		int			dline,
+	hline,
 	dcomplete,
-	hcomplete;
+	hcomplete,
+	offset,
+	chars_to_output;
 
 		if (cancel_pressed)
 			break;
@@ -1270,48 +1313,95 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 		pg_wcsformat((const unsigned char *) *ptr, strlen(*ptr), encoding,
 	 dlineptr, dheight);
 
-		line_count = 0;
+		dline = hline = 0;
 		dcomplete = hcomplete = 0;
+		offset = 0;
+		chars_to_output = dlineptr[dline].width;
 		while (!dcomplete || !hcomplete)
 		{
+			/* Left border */
 			if (opt_border == 2)
 fprintf(fout, %s , dformat-leftvrule);
+
+			/* Header */
 			if (!hcomplete)
 			{
-fprintf(fout, %-s%*s, hlineptr[line_count].ptr,
-		hwidth - hlineptr[line_count].width, );
+int swidth = hwidth - hlineptr[hline].width - 1;
+fprintf(fout, %-s, hlineptr[hline].ptr);
+if (swidth  0) /* spacer */
+	fprintf(fout, %*s, swidth, );
 
-if (!hlineptr[line_count + 1].ptr)
+if (!hlineptr[hline + 1].ptr)
+{
+	fputs( , fout);
 	hcomplete = 1;
+}
+else 
+{
+	fputs(format-nl_right, fout);
+	hline++;
+}
 			}
 			else
-fprintf(fout, %*s, hwidth, );
+fprintf(fout, %*s, hwidth + 1, );
 
+			/* Separator */
 			if (opt_border  0)
-fprintf(fout,  %s , dformat-midvrule);
-			else
-fputc(' ', fout);
+fprintf(fout, %s, dformat-midvrule);
 
+			/* Data */
 			if (!dcomplete)
 			{
-if (opt_border  2)
-	fprintf(fout, %s\n, dlineptr[line_count].ptr);
+int target_width,
+	bytes_to_output,
+	swidth;
+
+fputs(!dcomplete  !offset?  : format-wrap_left, fout);
+
+target_width = dwidth;
+bytes_to_output = strlen_max_width(dlineptr[dline].ptr + offset,
+   target_width, encoding);
+fputnbytes(fout, (char *)(dlineptr[dline].ptr + offset),
+		   bytes_to_output);
+
+chars_to_output -= target_width;
+offset += bytes_to_output;
+
+/* spacer */
+swidth = dwidth - target_width;
+if (swidth  0)
+	fprintf(fout, %*s, swidth, );
+
+if (!chars_to_output)
+{
+	if (!dlineptr[dline + 1].ptr)
+	{
+		fputs( , fout);
+		dcomplete = 1;
+	}
+	else
+	{
+		fputs(format-nl_right, fout);
+		dline++;
+		offset = 0;
+		chars_to_output = dlineptr[dline].width;
+	}
+}
 else
-	fprintf(fout, %-s%*s %s\n, dlineptr[line_count].ptr,
-			dwidth - dlineptr[line_count].width, ,

Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-11 Thread Greg Stark
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  | xxx |
| xx ; |
| xxx: xxx |
|    ; xxx |
| x  : xxx |
| xx ; xx  |
| xxx: xxx |
|    ; x   |
| x  : xxx |
| xx : xx  |
| xxx: x   |
|    : |
| x  : xxx |
| xx : xx  |
| xxx: x   |
|    : |
| x  : xxx |
| xx : xx  |
| xx : x   |
| x  : |
| xx : xxx |
| xx : xx  |
| xx : x   |
| xxx: |
| xx : |
|    : |
| xx : |
| x  : |
| xx : |
| xx   |
| xx   |
| xxx  |
++-+
stark=# select array_to_string(array_agg(repeat('x',x)),E'\n') as x
y
z
from generate_series(1,20) as x(x);

┌─[ RECORD 1 ]─┐
│ x↵│ x   ↵│
│ y↵│ xx  ↵│
│ z │ xxx ↵│
│   │ ↵│
│   │ x   ↵│
│   │ xx  ↵│
│   │ xxx ↵│
│   │ ↵│
│   │ x   ↵│
│   │ xx  ↵│
│   │ xxx ↵│
│   │ ↵│
│   │ …│
│   │…x   ↵│
│   │ …│
│   │…xx  ↵│
│   │ …│
│   │…xxx ↵│
│   │ …│
│   │…↵│
│   │ …│
│   │…x   ↵│
│   │ …│
│   │…xx  ↵│
│   │ …│
│   │…xxx ↵│
│   │ …│
│   │… │
└───┴──┘

stark=# \pset linestyle ascii
Line style (linestyle) is ascii.

stark=# select array_to_string(array_agg(repeat('x',x)),E'\n') as x
y
z
from generate_series(1,20) as x(x);
stark***# stark***# stark-***# +-[ RECORD 1 ]-+
| x+| x   +|
| y+| xx  +|
| z | xxx +|
|   | +|
|   | x   +|
|   | xx  +|
|   | xxx +|
|   | +|
|   | x   +|
|   | xx  +|
|   | xxx +|
|   | +|
|   | .|
|   |.x   +|
|   | .|
|   |.xx  +|
|   | .|
|   |.xxx +|
|   | .|
|   |.+|
|   | .|
|   |.x   +|
|   | .|
|   |.xx  +|
|   | .|
|   |.xxx +|
|   | .|
|   |. |
+---+--+

stark=# \pset linestyle old-ascii
Line style (linestyle) is old-ascii.

stark=# select array_to_string(array_agg(repeat('x',x)),E'\n') as x
y
z
from generate_series(1,20) as x(x);
stark# stark# stark-# 
+-[ RECORD 1 ]-+
| x | x|
| y | xx   |
| z | xxx  |
|   |  |
|   | x|
|   | xx   |
|   | xxx  |
|   |  |
|   | x|
|   | xx   |
|   | xxx  |
|   |  |
|   |  |
|   | x|
|   |  |
|   | xx   |
|   |  |
|   | xxx  |
|   |  |
|   |  |
|   |  |
|   | x|
|   |  |
|   | xx   |
|   |  |
|   | xxx  |
|   |  |
|   |  |
+---+--+

stark=# \pset expanded off
Expanded display (expanded) is off.

stark=# \pset columns 40
Target width (columns) is 40.

stark=# select array_to_string(array_agg(repeat('x',x)),E'\n') as x
y

Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-11 Thread Sergey Muraviov
I hope that I realized old-ascii logic correctly.


2014-04-11 19:10 GMT+04:00 Greg Stark st...@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  | xxx |
 | xx ; |
 | xxx: xxx |
 |    ; xxx |
 | x  : xxx |
 | xx ; xx  |
 | xxx: xxx |
 |    ; x   |
 | x  : xxx |
 | xx : xx  |
 | xxx: x   |
 |    : |
 | x  : xxx |
 | xx : xx  |
 | xxx: x   |
 |    : |
 | x  : xxx |
 | xx : xx  |
 | xx : x   |
 | x  : |
 | xx : xxx |
 | xx : xx  |
 | xx : x   |
 | xxx: |
 | xx : |
 |    : |
 | xx : |
 | x  : |
 | xx : |
 | xx   |
 | xx   |
 | xxx  |
 ++-+




-- 
Best regards,
Sergey Muraviov
From 69d845f05864a5d07a90ee20e10a5cb09b78d1d3 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Fri, 11 Apr 2014 20:55:17 +0400
Subject: [PATCH] Support for old-ascii mode

---
 src/bin/psql/print.c | 144 +++
 1 file changed, 122 insertions(+), 22 deletions(-)

diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 79fc43e..2c58cb5 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1234,13 +1234,56 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 			fprintf(fout, %s\n, cont-title);
 	}
 
+	if (cont-opt-format == PRINT_WRAPPED)
+	{
+		int output_columns = 0;
+
+		/*
+		 * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+		 */
+		if (cont-opt-columns  0)
+			output_columns = cont-opt-columns;
+		else
+		{
+			if (cont-opt-env_columns  0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+			else
+			{
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+	output_columns = screen_size.ws_col;
+			}
+#endif
+		}
+
+		output_columns -= hwidth;
+
+		if (opt_border == 0)
+			output_columns -= 1;
+		else
+		{
+			output_columns -= 3; /* -+- */
+
+			if (opt_border  1)
+output_columns -= 4; /* +--+ */
+		}
+
+		if (output_columns  0  dwidth  output_columns)
+			dwidth = output_columns;
+	}
+
 	/* print records */
 	for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
 	{
 		printTextRule pos;
-		int			line_count,
+		int			dline,
+	hline,
 	dcomplete,
-	hcomplete;
+	hcomplete,
+	offset,
+	chars_to_output;
 
 		if (cancel_pressed)
 			break;
@@ -1270,48 +1313,105 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 		pg_wcsformat((const unsigned char *) *ptr, strlen(*ptr), encoding,
 	 dlineptr, dheight);
 
-		line_count = 0;
+		dline = hline = 0;
 		dcomplete = hcomplete = 0;
+		offset = 0;
+		chars_to_output = dlineptr[dline].width;
 		while (!dcomplete || !hcomplete)
 		{
+			/* Left border */
 			if (opt_border == 2)
-fprintf(fout, %s , dformat-leftvrule);
+fputs(dformat-leftvrule, fout);
+
+			/* Header */
 			if (!hcomplete)
 			{
-fprintf(fout, %-s%*s, hlineptr[line_count].ptr,
-		hwidth - hlineptr[line_count].width, );
+int swidth = hwidth - hlineptr[hline].width - 1;
+fputs(hline? format-header_nl_left:  , fout);
+fprintf(fout, %-s, 

Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-11 Thread Alvaro Herrera
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 Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-11 Thread Sergey Muraviov
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 alvhe...@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 Herrerahttp://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services




-- 
Best regards,
Sergey Muraviov
\pset expanded on
\pset border 2
\pset columns 20
\pset format wrapped

\pset linestyle unicode 
postgres=# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
postgres# y,  array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
postgres# y
postgres# z from (select generate_series(1,10)) as t(n);
┌─[ RECORD 1 ]─┐
│ x↵│ x   ↵│
│ y │ xx  ↵│
│   │ xxx ↵│
│   │ ↵│
│   │ x   ↵│
│   │ xx  ↵│
│   │ xxx ↵│
│   │ ↵│
│   │ x   ↵│
│   │ xx   │
│ x↵│ …│
│ y↵│…yy  ↵│
│ z │ …│
│   │…↵│
│   │ …│
│   │…yy  ↵│
│   │ ↵│
│   │ yy  ↵│
│   │ ↵│
│   │ yy  ↵│
│   │ ↵│
│   │ yy  ↵│
│   │  │
└───┴──┘

postgres=# \pset linestyle ascii 
Line style (linestyle) is ascii.
postgres=# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y,  array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);
+-[ RECORD 1 ]-+
| x+| x   +|
| y | xx  +|
|   | xxx +|
|   | +|
|   | x   +|
|   | xx  +|
|   | xxx +|
|   | +|
|   | x   +|
|   | xx   |
| x+| .|
| y+|.yy  +|
| z | .|
|   |.+|
|   | .|
|   |.yy  +|
|   | +|
|   | yy  +|
|   | +|
|   | yy  +|
|   | +|
|   | yy  +|
|   |  |
+---+--+

postgres=# \pset linestyle old-ascii 
Line style (linestyle) is old-ascii.
postgres=# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y,  array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);
+-[ RECORD 1 ]-+
| x | x|
|+y : xx   |
|   : xxx  |
|   :  |
|   : x|
|   : xx   |
|   : xxx  |
|   :  |
|   : x|
|   : xx   |
| x |  |
|+y ; yy   |
|+z :  |
|   ;  |
|   :  |
|   ; yy   |
|   :  |
|   : yy   |
|   :  |
|   : yy   |
|   :  |
|   : yy   |
|   :  |
+---+--+



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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-11 Thread Greg Stark
Yeah, I think I agree. I'm pretty happy to commit it without old-ascii
doing anything special.

It looks 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.

I don't think this new output is very useful dive it just displays the
old-ascii info for the header cells. The header cells never wrap and often
have a lot of empty lines so it just looks like noise.

I do think the earlier change today was important. It looks great now with
the wrap and newline indicators in ascii and Unicode mode.

Fwiw I've switched my .psqlrc to use Unicode and wrapped=auto be default.
It makes psql way more usable. It's even better than my old technique of
running it in Emacs and scrolling left and right.

I'll take a look at it this evening and will add regression tests (and
probably more comments too!) and commit. I want to try adding Unicode
regression tests but I'm not sure what the state of the art is for Unicode
fallback behaviour on the build farm. I think there are some existing tests
we can copy iirc.

-- 
greg


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-10 Thread Greg Stark
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,
postgres=***# \pset
Border style (border) is 2.
Target width (columns) is 20.
Expanded display (expanded) is on.
Field separator (fieldsep) is |.
Default footer (footer) is on.
Output format (format) is wrapped.
Line style (linestyle) is unicode.
Null display (null) is .
Locale-adjusted numeric output (numericlocale) is off.
Pager (pager) usage is off.
Record separator (recordsep) is newline.
Table attributes (tableattr) unset.
Title (title) unset.
Tuples only (tuples_only) is off.

postgres=***# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y,  array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);

┌─[ RECORD 1 ]─┐
│ x │ x│
│ y │ xx   │
│   │ xxx  │
│   │  │
│   │ x│
│   │ xx   │
│   │ xxx  │
│   │  │
│   │ x│
│   │ xx   │
│ x │  │
│   │ yy   │
│ y │  │
│   │  │
│ z │  │
│   │ yy   │
│   │  │
│   │ yy   │
│   │  │
│   │ yy   │
│   │  │
│   │ yy   │
│   │  │
└───┴──┘

postgres=***# \pset linestyle ascii
Line style (linestyle) is ascii.

postgres=***# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y,  array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);

+-[ RECORD 1 ]-+
| x | x|
| y | xx   |
|   | xxx  |
|   |  |
|   | x|
|   | xx   |
|   | xxx  |
|   |  |
|   | x|
|   | xx   |
| x |  |
|   | yy   |
| y |  |
|   |  |
| z |  |
|   | yy   |
|   |  |
|   | yy   |
|   |  |
|   | yy   |
|   |  |
|   | yy   |
|   |  |
+---+--+

postgres=***# \pset columns 30
Target width (columns) is 30.

postgres=***# \pset linestyle unicode
Line style (linestyle) is unicode.

postgres=***# \pset columns 30
Target width (columns) is 30.

postgres=***# \pset expanded off
Expanded display (expanded) is off.

postgres=***# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y,  array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);

┌───┬┐
│ x↵│   x   ↵│
│ y │   y   ↵│
│   │   z│
├───┼┤
│ x↵│ yy…│
│ xx   ↵│…  ↵│
│ xxx  ↵│ yy…│
│  ↵│…yy↵│
│ x↵│ yy↵│
│ xx   ↵│   ↵│
│ xxx  ↵│ yy↵│
│  ↵│   ↵│
│ x↵│ yy↵│
│ x…│   ↵│
│…x │ yy↵│
│   ││
└───┴┘
(1 row)



postgres=***# \pset linestyle ascii
Line style (linestyle) is ascii.

postgres=***# select array_to_string(array_agg(repeat('x',n)),E'\n') as x
y,  array_to_string(array_agg(repeat('yy',10-n)),E'\n') as x
y
z from (select generate_series(1,10)) as t(n);

+---++
| x+|   x   +|
| y |   y   +|
|   |   z|
+---++
| x+| yy.|
| xx   +|.  +|
| xxx  +| yy.|
|  +|.yy+|
| x+| yy+|
| xx   +|   +|
| xxx  +| yy+|
|  +|   +|
| x+| yy+|
| x.|   +|
|.x | yy+|
|   ||
+---++

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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-10 Thread Sergey Muraviov
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 st...@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: [HACKERS] Problem with displaying wide tables in psql

2014-04-09 Thread Sergey Muraviov
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 +  680)
 if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)

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

 On Tue, Apr 8, 2014 at 12:19 PM, Andres Freund and...@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: [HACKERS] Problem with displaying wide tables in psql

2014-04-09 Thread Greg Stark
 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.


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-08 Thread Greg Stark
On Sat, Feb 15, 2014 at 11:08 AM, Emre Hasegeli e...@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


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-08 Thread Andres Freund
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


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-04-08 Thread Greg Stark
On Tue, Apr 8, 2014 at 12:19 PM, Andres Freund and...@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


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-02-17 Thread Emre Hasegeli
2014-02-16 18:37, Sergey Muraviov sergey.k.murav...@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.


fix_psql_print_aligned_vertical_v5.patch
Description: Binary data

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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-02-17 Thread Sergey Muraviov
Thanks.


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

 2014-02-16 18:37, Sergey Muraviov sergey.k.murav...@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: [HACKERS] Problem with displaying wide tables in psql

2014-02-16 Thread Sergey Muraviov
Hi.

Thanks for your review.

2014-02-15 20:08 GMT+04:00 Emre Hasegeli e...@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.murav...@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
From 48ba7ed8c5ff82cdc1c912ff9ac966962f18ce54 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Sun, 16 Feb 2014 20:00:10 +0400
Subject: [PATCH] Now patch works with PRINT_WRAPPED option only

---
 src/bin/psql/print.c | 79 ++--
 1 file changed, 71 insertions(+), 8 deletions(-)

diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 79fc43e..d7bf412 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1234,6 +1234,45 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 			fprintf(fout, %s\n, cont-title);
 	}
 
+	if (cont-opt-format == PRINT_WRAPPED)
+	{
+		int output_columns = 0;
+		/*
+		 * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+		 */
+		if (cont-opt-columns  0)
+			output_columns = cont-opt-columns;
+		else
+		{
+			if (cont-opt-env_columns  0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+			else
+			{
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+	output_columns = screen_size.ws_col;
+			}
+#endif
+		}
+
+		output_columns -= hwidth;
+
+		if (opt_border == 0)
+			output_columns -= 1;
+		else
+		{
+			output_columns -= 3; /* -+- */
+
+			if (opt_border  1)
+output_columns -= 4; /* +--+ */
+		}
+
+		if ((output_columns  0)  (dwidth  output_columns))
+			dwidth = output_columns;
+	}
+
 	/* print records */
 	for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
 	{
@@ -1292,20 +1331,45 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 			else
 fputc(' ', fout);
 
-			if (!dcomplete)
+			if ((!dcomplete)  (dlineptr[line_count].width  0))
 			{
-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);
+int offset = 0;
+int chars_to_output = dlineptr[line_count].width;
+while (chars_to_output  0)
+{
+	int target_width, bytes_to_output;
+	if (offset  0)
+	{
+		if (opt_border == 2)
+			fprintf(fout, %s , dformat-leftvrule);
+
+		fprintf(fout, %*s, hwidth,  );
+
+		if (opt_border  0)
+			fprintf(fout,  %s , dformat-midvrule);
+		else
+			fputc(' ', fout);
+	}
+
+	target_width = dwidth;
+	bytes_to_output = strlen_max_width(dlineptr[line_count].ptr + offset,
+		target_width, encoding);
+	fputnbytes(fout, (char *)(dlineptr[line_count].ptr + offset), bytes_to_output);
+	chars_to_output -= target_width;
+	offset += bytes_to_output;
+
+	if (opt_border  2)
+		fputc('\n', fout);
+	else
+		fprintf(fout, %*s %s\n, dwidth - target_width, , dformat-rightvrule);
+}
 
 if (!dlineptr[line_count + 1].ptr)
 	dcomplete = 1;
 			}
 			else
 			{
+dcomplete = 1;
 if (opt_border  2)
 	fputc('\n', fout);
 else
@@ -2175,7 +2239,6 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout)
 /* Public functions		*/
 //
 
-
 /*
  * PageOutput
  *
-- 
1.8.5.3


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


Re: [HACKERS] Problem with displaying wide tables in psql

2014-02-15 Thread Emre Hasegeli
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.murav...@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.


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


Re: [HACKERS] Problem with displaying wide tables in psql

2013-12-24 Thread Peter Eisentraut
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.



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


Re: [HACKERS] Problem with displaying wide tables in psql

2013-12-24 Thread Sergey Muraviov
fixed


2013/12/24 Peter Eisentraut pete...@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
From be9f01777599dc5e84c417e5cae56459677a88d4 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Wed, 11 Dec 2013 20:17:26 +0400
Subject: [PATCH 1/2] wrapped tables in expanded mode

---
 src/bin/psql/print.c | 123 ---
 1 file changed, 118 insertions(+), 5 deletions(-)

diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 736225c..4c37f7d 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -124,6 +124,7 @@ const printTextFormat pg_utf8format =
 
 /* Local functions */
 static int	strlen_max_width(unsigned char *str, int *target_width, int encoding);
+static bool IsWrappingNeeded(const printTableContent *cont, bool is_pager);
 static void IsPagerNeeded(const printTableContent *cont, const int extra_lines, bool expanded,
 			  FILE **fout, bool *is_pager);
 
@@ -1234,6 +1235,45 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 			fprintf(fout, %s\n, cont-title);
 	}
 
+	if (IsWrappingNeeded(cont, is_pager))
+	{
+		int output_columns = 0;
+		/*
+		 * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+		 */
+		if (cont-opt-columns  0)
+			output_columns = cont-opt-columns;
+		else
+		{
+			if (cont-opt-env_columns  0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+			else
+			{
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+	output_columns = screen_size.ws_col;
+			}
+#endif
+		}
+
+		output_columns -= hwidth;
+
+		if (opt_border == 0)
+			output_columns -= 1;
+		else
+		{
+			output_columns -= 3; /* -+- */
+
+			if (opt_border  1) 
+output_columns -= 4; /* +--+ */
+		}
+
+		if ((output_columns  0)  (dwidth  output_columns))
+			dwidth = output_columns;
+	}
+
 	/* print records */
 	for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
 	{
@@ -1294,12 +1334,49 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 
 			if (!dcomplete)
 			{
-if (opt_border  2)
-	fprintf(fout, %s\n, dlineptr[line_count].ptr);
+if (dlineptr[line_count].width  dwidth)
+{
+	int offset = 0;
+	int chars_to_output = dlineptr[line_count].width;
+	while (chars_to_output  0)
+	{
+		int target_width, bytes_to_output;
+
+		if (offset  0)
+		{
+			if (opt_border == 2)
+fprintf(fout, %s , dformat-leftvrule);
+
+			fprintf(fout, %*s, hwidth,  );
+	
+			if (opt_border  0)
+fprintf(fout,  %s , dformat-midvrule);
+			else
+fputc(' ', fout);
+		}
+
+		target_width = dwidth;
+		bytes_to_output = strlen_max_width(dlineptr[line_count].ptr + offset, 
+			target_width, encoding);
+		fputnbytes(fout, (char *)(dlineptr[line_count].ptr + offset), bytes_to_output);
+		chars_to_output -= target_width;
+		offset += bytes_to_output;
+		
+		if (opt_border  2)
+			fputc('\n', fout);
+		else
+			fprintf(fout, %*s %s\n, dwidth - target_width, , dformat-rightvrule);
+	}
+}
 else
-	fprintf(fout, %-s%*s %s\n, dlineptr[line_count].ptr,
-			dwidth - dlineptr[line_count].width, ,
-			dformat-rightvrule);
+{
+	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);
+}
 
 if (!dlineptr[line_count + 1].ptr)
 	dcomplete = 1;
@@ -2175,6 +2252,42 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout)
 /* Public functions		*/
 //
 
+/*
+ * IsWrappingNeeded
+ *
+ * Tests if wrapping is needed
+ */
+static bool
+IsWrappingNeeded(const printTableContent *cont,  bool is_pager)
+{
+	const char *pagerprog = 0, 
+*less_options = 0;
+
+	if ((cont-opt-format == PRINT_WRAPPED) || (is_pager == false))
+		return true;
+
+	pagerprog = getenv(PAGER);
+	if (!pagerprog)
+		pagerprog = DEFAULT_PAGER;
+
+	if (strcmp(pagerprog, less) != 0)
+		return true;
+
+	less_options = getenv(LESS);
+	if (!less_options)
+		return true;
+/*
+ * Test for -S option
+ * Causes  lines  longer than the screen width to be chopped rather
+ * than folded.  That is, the portion of a long line that does  not
+ * fit  in  the  screen width is not shown.  The default is to fold
+ * long lines; that is, display the remainder on the next line.
+ */
+	if (strchr(less_options, 'S'))
+		return false;
+	else
+		return true;
+}
 
 /*
  * PageOutput
-- 
1.8.4.2


From 9c4076796386ee3062fcc51272eb3e6e9b66bb1d Mon Sep 17 00:00:00 2001
From: Sergey Muraviov 

Re: [HACKERS] Problem with displaying wide tables in psql

2013-12-18 Thread Sergey Muraviov
Hello

2013/12/18 Sameer Thakur samthaku...@gmail.com

 On Wed, Dec 11, 2013 at 11:13 PM, Sergey Muraviov
 sergey.k.murav...@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: [HACKERS] Problem with displaying wide tables in psql

2013-12-17 Thread Sameer Thakur
On Wed, Dec 11, 2013 at 11:13 PM, Sergey Muraviov
sergey.k.murav...@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


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


Re: [HACKERS] Problem with displaying wide tables in psql

2013-12-11 Thread Sergey Muraviov
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.ja...@gmail.com

 On Mon, Dec 2, 2013 at 10:45 PM, Sergey Muraviov 
 sergey.k.murav...@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
From be9f01777599dc5e84c417e5cae56459677a88d4 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Wed, 11 Dec 2013 20:17:26 +0400
Subject: [PATCH] wrapped tables in expanded mode

---
 src/bin/psql/print.c | 123 ---
 1 file changed, 118 insertions(+), 5 deletions(-)

diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 736225c..4c37f7d 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -124,6 +124,7 @@ const printTextFormat pg_utf8format =
 
 /* Local functions */
 static int	strlen_max_width(unsigned char *str, int *target_width, int encoding);
+static bool IsWrappingNeeded(const printTableContent *cont, bool is_pager);
 static void IsPagerNeeded(const printTableContent *cont, const int extra_lines, bool expanded,
 			  FILE **fout, bool *is_pager);
 
@@ -1234,6 +1235,45 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 			fprintf(fout, %s\n, cont-title);
 	}
 
+	if (IsWrappingNeeded(cont, is_pager))
+	{
+		int output_columns = 0;
+		/*
+		 * Choose target output width: \pset columns, or $COLUMNS, or ioctl
+		 */
+		if (cont-opt-columns  0)
+			output_columns = cont-opt-columns;
+		else
+		{
+			if (cont-opt-env_columns  0)
+output_columns = cont-opt-env_columns;
+#ifdef TIOCGWINSZ
+			else
+			{
+struct winsize screen_size;
+
+if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)
+	output_columns = screen_size.ws_col;
+			}
+#endif
+		}
+
+		output_columns -= hwidth;
+
+		if (opt_border == 0)
+			output_columns -= 1;
+		else
+		{
+			output_columns -= 3; /* -+- */
+
+			if (opt_border  1) 
+output_columns -= 4; /* +--+ */
+		}
+
+		if ((output_columns  0)  (dwidth  output_columns))
+			dwidth = output_columns;
+	}
+
 	/* print records */
 	for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
 	{
@@ -1294,12 +1334,49 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
 
 			if (!dcomplete)
 			{
-if (opt_border  2)
-	fprintf(fout, %s\n, dlineptr[line_count].ptr);
+if (dlineptr[line_count].width  dwidth)
+{
+	int offset = 0;
+	int chars_to_output = dlineptr[line_count].width;
+	while (chars_to_output  0)
+	{
+		int target_width, bytes_to_output;
+
+		if (offset  0)
+	

Re: [HACKERS] Problem with displaying wide tables in psql

2013-12-09 Thread Jeff Janes
On Mon, Dec 2, 2013 at 10:45 PM, Sergey Muraviov 
sergey.k.murav...@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: [HACKERS] Problem with displaying wide tables in psql

2013-12-05 Thread Robert Haas
On Thu, Dec 5, 2013 at 1:09 AM, Sergey Muraviov
sergey.k.murav...@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


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


Re: [HACKERS] Problem with displaying wide tables in psql

2013-12-04 Thread Alexander Korotkov
On Wed, Dec 4, 2013 at 11:20 AM, Sergey Muraviov 
sergey.k.murav...@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: [HACKERS] Problem with displaying wide tables in psql

2013-12-04 Thread Pavel Stehule
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.murav...@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.steh...@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.murav...@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
 ]---+--

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Re: [HACKERS] Problem with displaying wide tables in psql

2013-12-04 Thread Sergey Muraviov
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.steh...@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.murav...@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.steh...@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.murav...@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
 ]---+--

 

 

 

 

 

 

Re: [HACKERS] Problem with displaying wide tables in psql

2013-12-03 Thread Pavel Stehule
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.murav...@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 | 

Re: [HACKERS] Problem with displaying wide tables in psql

2013-12-03 Thread Sergey Muraviov
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.steh...@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.murav...@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 |