Re: [HACKERS] wrapping in extended mode doesn't work well with default pager
So what's wrong with the patch? And what should I change in it for 9.5? 2014-07-07 3:12 GMT+04:00 Greg Stark st...@mit.edu: On Sun, Jul 6, 2014 at 8:40 AM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: Is there anyone who can commit the patch? So what I'm inclined to do here (sigh) is commit it into 9.5 and revert it in 9.4. I think it's an improvement but I there's enough confusion and surprise about the changes from people who weren't expecting them and enough surprising side effects from things like check_postgres that letting it simmer for a full release so people can get used to it might be worthwhile. -- greg -- Best regards, Sergey Muraviov
Re: [HACKERS] wrapping in extended mode doesn't work well with default pager
Hi. Is there anyone who can commit the patch? 2014-06-25 20:17 GMT+04:00 Pavel Stehule pavel.steh...@gmail.com: 2014-06-24 19:45 GMT+02:00 Sergey Muraviov sergey.k.murav...@gmail.com: Hi. Is there any problem with the patch? I tested it and I had not any issue with last version So, please, commit it Regards Pavel 2014-06-17 0:21 GMT+04:00 Greg Stark st...@mit.edu: On Mon, Jun 16, 2014 at 9:05 PM, Robert Haas robertmh...@gmail.com wrote: So, it seems like we need to do something about this one way or another. Who's working on that? So I'm fine finishing what I started. I've just been a bit busy this past week. My inclination is to try to push forward and commit this patch, document the changes and make sure we check for any consequences of them. The alternate plan is to revert it for 9.4 and commit the changes to 9.5 and that gives us more time to be sure we're ok with them. -- greg -- Best regards, Sergey Muraviov -- Best regards, Sergey Muraviov
Re: [HACKERS] wrapping in extended mode doesn't work well with default pager
Hi. Is there any problem with the patch? 2014-06-17 0:21 GMT+04:00 Greg Stark st...@mit.edu: On Mon, Jun 16, 2014 at 9:05 PM, Robert Haas robertmh...@gmail.com wrote: So, it seems like we need to do something about this one way or another. Who's working on that? So I'm fine finishing what I started. I've just been a bit busy this past week. My inclination is to try to push forward and commit this patch, document the changes and make sure we check for any consequences of them. The alternate plan is to revert it for 9.4 and commit the changes to 9.5 and that gives us more time to be sure we're ok with them. -- greg -- Best regards, Sergey Muraviov
Re: [HACKERS] wrapping in extended mode doesn't work well with default pager
Please check this patch.
2014-05-12 22:56 GMT+04:00 Sergey Muraviov sergey.k.murav...@gmail.com:
Hi.
I'll try to fix it tomorrow.
2014-05-12 18:42 GMT+04:00 Tom Lane t...@sss.pgh.pa.us:
Greg Stark st...@mit.edu writes:
On Mon, May 12, 2014 at 2:12 PM, Greg Stark st...@mit.edu wrote:
Hm, there was an off by one error earlier in some cases, maybe we
fixed it by breaking other case. Will investigate.
Those spaces are coming from the ascii wrapping indicators. i.e. the
periods in:
Ah. I wonder whether anyone will complain that the format changed?
Apparently we used to print those with border=1 in normal mode but in
expanded mode we left out the space for those on the outermost edges
since there was no need for them. If we put them in for wrapped mode
then we'll be inconsistent if we don't for nonwrapped mode though. And
if we don't put them in for wrapped mode then there's no way to
indicate wrapping versus newlines.
Barring anyone complaining that the format changed, I'd say the issue
is not that you added them but that the accounting for line length
fails to include them.
regards, tom lane
--
Best regards,
Sergey Muraviov
--
Best regards,
Sergey MuraviovH
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 62850d8..69f4efe 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1258,45 +1258,67 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
if (cont-opt-format == PRINT_WRAPPED)
{
/*
- * Calculate the available width to wrap the columns to after
- * subtracting the maximum header width and separators. At a minimum
- * enough to print [ RECORD N ]
+ * Separators width
*/
unsigned int width,
+ min_width,
swidth;
if (opt_border == 0)
- swidth = 1; /* header data */
+ /*
+ * For border = 0, one space in the middle.
+ */
+ swidth = 1;
else if (opt_border == 1)
- swidth = 3; /* header | data */
- else
- swidth = 7; /* | header | data | */
-
- /* Wrap to maximum width */
- width = dwidth + swidth + hwidth;
- if ((output_columns 0) (width output_columns))
{
- dwidth = output_columns - hwidth - swidth;
- width = output_columns;
+ /*
+ * For border = 1, one for the pipe (|) in the middle
+ * between the two spaces.
+ */
+ swidth = 3;
}
+ else
+ /*
+ * For border = 2, two more for the pipes (|) at the begging and
+ * at the end of the lines.
+ */
+ swidth = 7;
- /* Wrap to minimum width */
+ min_width = hwidth + swidth + 3;
+
+ /*
+ * Record header width
+ */
if (!opt_tuples_only)
{
- int delta = 1 + log10(cont-nrows) - width;
-
+ /*
+ * Record number
+ */
+ unsigned int rwidth = 1 + log10(cont-nrows);
if (opt_border == 0)
-delta += 6; /* * RECORD */
+rwidth += 9; /* * RECORD */
else if (opt_border == 1)
-delta += 10; /* -[ RECORD ] */
+rwidth += 12; /* -[ RECORD ] */
else
-delta += 15; /* +-[ RECORD ]-+ */
+rwidth += 15; /* +-[ RECORD ]-+ */
- if (delta 0)
-dwidth += delta;
+ if (rwidth min_width)
+min_width = rwidth;
}
- else if (dwidth 3)
- dwidth = 3;
+
+ if ((hheight 1) (opt_border 2))
+ hwidth++; /* for wrapping indicator*/
+
+ /* Wrap to minimum width */
+ width = hwidth + swidth + dwidth;
+ if ((width min_width) || (output_columns min_width))
+ dwidth = min_width - hwidth - swidth;
+ else if ((output_columns 0)
+ (width output_columns))
+ /*
+ * Wrap to maximum width
+ */
+ dwidth = output_columns - hwidth - swidth;
}
/* print records */
@@ -1357,12 +1379,17 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
int swidth,
twidth = hwidth + 1;
-fputs(hline ? format-header_nl_left : , fout);
+if ((hheight 1) || (opt_border == 2))
+ fputs(hline ? format-header_nl_left : , fout);
strlen_max_width(hlineptr[hline].ptr, twidth,
encoding);
fprintf(fout, %-s, hlineptr[hline].ptr);
swidth = hwidth - twidth;
+if ((hheight 1)
+ (opt_border 2)
+ (cont-opt-format == PRINT_WRAPPED))
+ swidth--;
if (swidth 0) /* spacer */
fprintf(fout, %*s, swidth, );
@@ -1382,7 +1409,11 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
else
{
/* Header exhausted but more data for column */
-fprintf(fout, %*s, hwidth + 2, );
+unsigned int ewidth = hwidth + 2;
+if ((opt_border 2)
+ (cont-opt-format == PRINT_WRAPPED))
+ ewidth--;
+fprintf(fout, %*s, ewidth, );
}
/* Separator */
@@ -1401,13 +1432,24 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
/* Data */
if (!dcomplete)
{
-int target_width,
+int target_width = dwidth,
bytes_to_output,
swidth;
-fputs(!dcomplete !offset ? : format-wrap_left, fout);
+if (dheight 1)
+{
+ fputs
[HACKERS] Typo in release notes
Hi. Here's a patch that fixes it. -- Best regards, Sergey Muraviov diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml index cabfbdd..0b6f383 100644 --- a/doc/src/sgml/release-9.4.sgml +++ b/doc/src/sgml/release-9.4.sgml @@ -1587,7 +1587,7 @@ para Add variables link linkend=plpgsql-extra-checksvarnameplpgsql.extra_warnings//link -and varnameplpgsql.extra_errors/to enable additional PL/pgSQL +and varnameplpgsql.extra_errors/ to enable additional PL/pgSQL warnings and errors (Marko Tiikkaja, Petr Jelinek) /para -- 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] sepgsql: label regression test failed
Hi.
Some regression tests for sepgsql still not work on Fedora 20:
== running regression test queries==
test label... FAILED
test dml ... ok
test ddl ... FAILED
test alter... FAILED
test misc ... ok
==
3 of 5 tests failed.
==
$ sestatus
SELinux status: enabled
SELinuxfs mount:/sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 29
$ uname -i -o -r
3.14.3-200.fc20.x86_64 x86_64 GNU/Linux
$ /usr/local/pgsql/bin/postgres --version
postgres (PostgreSQL) 9.4beta1
PS
I've got this compiler warning:
relation.c: In function ‘sepgsql_relation_drop’:
relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
sepgsql_avc_check_perms(object,
^
2013-12-25 0:34 GMT+04:00 Kohei KaiGai kai...@kaigai.gr.jp:
Hello,
It seems to me changes in the base security policy on Fedora affected to
the regression test. Our test cases for sepgsql_setcon() utilizes the MCS
rules, that prevents domain transition from narrow categories to wider
ones,
to control the success cases and failure cases.
However, its coverage was changed. It was applied all the domains in the
system, thus unconfined_t domain had been enforced by MCS rules.
But now, it shall be applied only domains with mcs_constrained_type
attribute.
[kaigai@vmlinux tmp]$ diff -up old/policy/mcs new/policy/mcs
:
snip
:
mlsconstrain process { transition dyntransition }
- (( h1 dom h2 ) or ( t1 == mcssetcats ));
+ (( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
Probably, we need to define a domain by ourselves for regression test to
ensure
the test stability, not using the system unconfined domain that has
different
meaning by release.
I'll make a patch. Please wait for a while.
Thanks for your test reports.
2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com:
# semodule -l | grep sepgslq
sepgsql-regtest 1.07
Full list of modules is in attachment.
2013/12/18 Kohei KaiGai kai...@kaigai.gr.jp
Could you show me semodule -l on your environment?
I believe security policy has not been changed between F19 and F20...
Thanks,
2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com:
Hi
I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora
20
and
met with a label regression test failure.
PS
I've got some warning during build process.
--
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
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Best regards,
Sergey Muraviov
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Best regards,
Sergey Muraviov
regression.diffs
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] wrapping in extended mode doesn't work well with default pager
Hi. I'll try to fix it tomorrow. 2014-05-12 18:42 GMT+04:00 Tom Lane t...@sss.pgh.pa.us: Greg Stark st...@mit.edu writes: On Mon, May 12, 2014 at 2:12 PM, Greg Stark st...@mit.edu wrote: Hm, there was an off by one error earlier in some cases, maybe we fixed it by breaking other case. Will investigate. Those spaces are coming from the ascii wrapping indicators. i.e. the periods in: Ah. I wonder whether anyone will complain that the format changed? Apparently we used to print those with border=1 in normal mode but in expanded mode we left out the space for those on the outermost edges since there was no need for them. If we put them in for wrapped mode then we'll be inconsistent if we don't for nonwrapped mode though. And if we don't put them in for wrapped mode then there's no way to indicate wrapping versus newlines. Barring anyone complaining that the format changed, I'd say the issue is not that you added them but that the accounting for line length fails to include them. regards, tom lane -- Best regards, Sergey Muraviov
Re: [HACKERS] Problem with displaying wide tables in psql
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
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
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, hlineptr
Re: [HACKERS] Problem with displaying wide tables in psql
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
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
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
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
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] extension_control_path
Hi. Now it looks fine for me. 2014-01-28 Dimitri Fontaine dimi...@2ndquadrant.fr: Hi, Sergey Muraviov sergey.k.murav...@gmail.com writes: Now patch applies cleanly and works. :-) Cool ;-) But I have some notes: 1. There is an odd underscore character in functions find_in_extension_control_path and list_extension_control_paths: \extension_control__path\ Fixed in the new version of the patch, attached. 2. If we have several versions of one extension in different directories (which are listed in extension_control_path parameter) then we get strange output from pg_available_extensions and pg_available_extension_versions views (Information about extension, whose path is at the beginning of the list, is duplicated). And only one version of the extension can be created. Fixed. 3. It would be fine to see an extension control path in pg_available_extensions and pg_available_extension_versions views (in separate column or within of extension name). I think the on-disk location is an implementation detail and decided in the attached version not to change those system view definitions. 4. Perhaps the CREATE EXTENSION command should be improved to allow creation of the required version of the extension. So we can use different versions of extensions in different databases. Fixed in the attached. I also fixed ALTER EXTENSION UPDATE to search for udpate scripts in the same directory where the main control file is found, but I suspect this part requires more thinking. When we ALTER EXTENSION UPDATE we might now have several places where we find extname.control files, with possibly differents default_version properties. In the attached, we select the directory containing the control file where default_version matches the already installed extension version. That matches with a model where the new version of the extension changes the default_version in an auxiliary file. We might want to instead match on the default_version in the control file to match with the new version we are asked to upgrade to. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Best regards, Sergey Muraviov
Re: [HACKERS] extension_control_path
Hi Now patch applies cleanly and works. :-) But I have some notes: 1. There is an odd underscore character in functions find_in_extension_control_path and list_extension_control_paths: \extension_control__path\ 2. If we have several versions of one extension in different directories (which are listed in extension_control_path parameter) then we get strange output from pg_available_extensions and pg_available_extension_versions views (Information about extension, whose path is at the beginning of the list, is duplicated). And only one version of the extension can be created. See examples: /extensions/ ├── postgis-2.0.4 │ ├── postgis--2.0.4.sql │ └── postgis.control └── postgis-2.1.1 ├── postgis--2.1.1.sql └── postgis.control = postgresql.conf: extension_control_path = '/extensions/postgis-2.0.4:/extensions/postgis-2.1.1' postgres=# table pg_catalog.pg_available_extensions; name | default_version | installed_version | comment -+-+---+- postgis | 2.0.4 | | PostGIS geometry, geography, and raster spatial types and functions postgis | 2.0.4 | | PostGIS geometry, geography, and raster spatial types and functions (2 rows) postgres=# table pg_catalog.pg_available_extension_versions; name | version | installed | superuser | relocatable | schema | requires | comment -+-+---+---+-++--+- postgis | 2.0.4 | f | t | t || | PostGIS geometry, geography, and raster spatial types and functions postgis | 2.0.4 | f | t | t || | PostGIS geometry, geography, and raster spatial types and functions (2 rows) = postgresql.conf: extension_control_path = '/extensions/postgis-2.1.1:/extensions/postgis-2.0.4' postgres=# table pg_catalog.pg_available_extensions; name | default_version | installed_version | comment -+-+---+- postgis | 2.1.1 | | PostGIS geometry, geography, and raster spatial types and functions postgis | 2.1.1 | | PostGIS geometry, geography, and raster spatial types and functions (2 rows) postgres=# create extension postgis; CREATE EXTENSION postgres=# SELECT PostGIS_version(); postgis_version --- 2.1 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 (1 row) postgres=# table pg_catalog.pg_available_extensions; name | default_version | installed_version | comment -+-+---+- postgis | 2.1.1 | 2.1.1 | PostGIS geometry, geography, and raster spatial types and functions postgis | 2.1.1 | 2.1.1 | PostGIS geometry, geography, and raster spatial types and functions (2 rows) 3. It would be fine to see an extension control path in pg_available_extensions and pg_available_extension_versions views (in separate column or within of extension name). 4. Perhaps the CREATE EXTENSION command should be improved to allow creation of the required version of the extension. So we can use different versions of extensions in different databases. PS Sorry for my English. 2014/1/24 Fabrízio de Royes Mello fabriziome...@gmail.com On Fri, Jan 24, 2014 at 6:57 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Sergey Muraviov sergey.k.murav...@gmail.com writes: I can't apply the patch. Did you try using the `patch`(1) command? The PostgreSQL project policy is to not use the git format when sending patches to the mailing list, prefering the context diff format. So you need to resort to using the basic patch commands rather than the modern git tooling. See also: http://wiki.postgresql.org/wiki/Submitting_a_Patch Patches must be in a format which provides context (eg: Context Diff); 'normal' or 'plain' diff formats are not acceptable. Would be nice if we can use git apply command... :-) -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Timbira: http://www.timbira.com.br Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello -- Best regards, Sergey Muraviov
Re: [HACKERS] extension_control_path
Hi. I can't apply the patch. $ git apply --stat ~/Downloads/extension_control_path.v0.patch fatal: unrecognized input 2014/1/14 Dimitri Fontaine dimi...@2ndquadrant.fr Hi, Please find attached to this email a patch implementing a new GUC that allows users to setup a list of path where PostgreSQL will search for the extension control files at CREATE EXTENSION time. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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: [HACKERS] Problem with displaying wide tables in psql
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
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
[HACKERS] sepgsql: label regression test failed
Hi I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20 and met with a label regression test failure. PS I've got some warning during build process. -- Best regards, Sergey Muraviov regression.out Description: Binary data regression.diffs Description: Binary data warnings 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] sepgsql: label regression test failed
# semodule -l | grep sepgslq sepgsql-regtest 1.07 Full list of modules is in attachment. 2013/12/18 Kohei KaiGai kai...@kaigai.gr.jp Could you show me semodule -l on your environment? I believe security policy has not been changed between F19 and F20... Thanks, 2013/12/18 Sergey Muraviov sergey.k.murav...@gmail.com: Hi I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20 and met with a label regression test failure. PS I've got some warning during build process. -- 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 -- KaiGai Kohei kai...@kaigai.gr.jp -- Best regards, Sergey Muraviov modules 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
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
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
[HACKERS] Problem with displaying wide tables in psql
,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
From 72cd7ec1d52b1d49e2f910d2677e331ea3088046 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov sergey.k.murav...@gmail.com
Date: Sun, 1 Dec 2013 14:18:11 +0400
Subject: [PATCH] print_aligned_vertical function has been fixed
---
src/bin/psql/print.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 736225c..f788928 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -1234,6 +1234,17 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
fprintf(fout, %s\n, cont-title);
}
+#ifdef TIOCGWINSZ
+ int max_dwidth = 0;
+ struct winsize screen_size;
+ ioctl(fileno(stdout), TIOCGWINSZ, screen_size);
+ max_dwidth = screen_size.ws_col - hwidth;
+ if (opt_border 0)
+ max_dwidth -= ((opt_border == 2) ? 7: 3); /* +--+--+ : -+- */
+
+ if (dwidth max_dwidth)
+ dwidth = max_dwidth;
+#endif
/* print records */
for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
{
@@ -1294,6 +1305,15 @@ print_aligned_vertical(const printTableContent *cont, FILE *fout)
if (!dcomplete)
{
+#ifdef TIOCGWINSZ
+if (dlineptr[line_count].width dwidth)
+{
+ if (opt_border == 2)
+ dlineptr[line_count].width = dwidth - 2 + screen_size.ws_col - (dlineptr[line_count].width - dwidth - 2) % screen_size.ws_col;
+ else
+ dlineptr[line_count].width = dwidth;
+}
+#endif
if (opt_border 2)
fprintf(fout, %s\n, dlineptr[line_count].ptr);
else
--
1.8.3.1
--
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
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
