Unicode UTF-8 table formatting for psql text output
in [PgSql]
|
Prev: Hot Standby 0.2.1
Next: Rejecting weak passwords
From: Roger Leigh on 25 Oct 2009 19:48 On Sat, Oct 24, 2009 at 06:23:24PM +0100, Roger Leigh wrote: > On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote: > > I like the new Unicode tables, but the marking of continuation lines > > looks pretty horrible: > > > > List of databases > > Name â Owner â Encoding â Collation â Ctype â Access > > privileges > > ââââââââââââââââ¼ââââââââ¼âââââââââââ¼ââââââââââââ¼ââââââââ¼âââââââââââââââââââ > > pl_regression â peter â LATIN2 â cs_CZ â cs_CZ â > > postgres â peter â LATIN2 â cs_CZ â cs_CZ â > > template0 â peter â LATIN2 â cs_CZ â cs_CZ â =c/peter > > â· â· â· â· â peter=CTc/peter > > template1 â peter â LATIN2 â cs_CZ â cs_CZ â =c/peter > > â· â· â· â· â peter=CTc/peter > > (4 rows) Just for reference, this is what the output looks like (abridged) using the attached patch. Should display fine if your mail client handles UTF-8 messages correctly: rleigh=# \l List of databases Name â Owner â Encoding â Collation â Ctype â Access privileges ââââââââââââââââââ¼âââââââââââ¼âââââââââââ¼ââââââââââââââ¼ââââââââââââââ¼âââââââââââââââââââââââ merkelpb â rleigh â UTF8 â en_GB.UTF-8 â en_GB.UTF-8 â postgres â postgres â UTF8 â en_GB.UTF-8 â en_GB.UTF-8 â projectb â rleigh â UTF8 â en_GB.UTF-8 â en_GB.UTF-8 â rleigh â rleigh â UTF8 â en_GB.UTF-8 â en_GB.UTF-8 â [â¦] template0 â postgres â UTF8 â en_GB.UTF-8 â en_GB.UTF-8 â =c/postgres âµ â â â â â postgres=CTc/postgres template1 â postgres â UTF8 â en_GB.UTF-8 â en_GB.UTF-8 â =c/postgres âµ â â â â â postgres=CTc/postgres [â¦] (17 rows) > > This looks more like a rendering mistake than something sensible, and > > also it doesn't actually help the viewer to tell what lines are > > continued, which was the original purpose. > > I've worked on a solution to this, and the preliminary patch for this > is attached. Note there are additional comments in the patch text. I've attached an updated version of the patch. This now - adds one column extra padding in wrapped mode if border=0 to allow correct display of wrap marks on the rightmost column. Removed special cases needed to suppress marks on the rightmost column. - updated unicode symbols to use more commonly-available symbol (ellipsis) rather than hooked arrows. Also makes wrapping more visually distinct cf. newlines. The CR and ellipsis symbols are commonly available in several character sets other than unicode, and are available in many common fonts, including all the Windows monospaced terminal fonts. Symbol availability isn't an issue on GNU/Linux. - updated ASCII symbols to use similar-looking symbols to the Unicode ones. - added some more comments to code - removed redundant enum values I've also attached a trivial test script to run through psql to test the wrapping, as well as the output I get for psql from 8.4.1 and the current mainline (both Unicode and ASCII) for comparison. Hopefully I'm not the only one that finds the proposed change clearer and more logical than the existing display! There's just one tiny display glitch I can see, and that's if you have mixed wrapping and newlines, you miss the lefthand wrap mark if the line is the last wrapped line and it ends in a newline. It might not be possible to pick that up if we can't discover that from the line state when printing out the line. Might possibly require storing the wrap state so we know what happened on the previous line, though if there's a slightly cleverer approach to detecting if we're already wrapped that would be better. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
From: Roger Leigh on 25 Oct 2009 20:10 On Sun, Oct 25, 2009 at 11:48:27PM +0000, Roger Leigh wrote: > There's just one tiny display glitch I can see, and that's if you have > mixed wrapping and newlines, you miss the lefthand wrap mark if the line > is the last wrapped line and it ends in a newline. It might not be > possible to pick that up if we can't discover that from the line state > when printing out the line. Might possibly require storing the wrap > state so we know what happened on the previous line, though if there's > a slightly cleverer approach to detecting if we're already wrapped > that would be better. This appears simpler and more robust, so I've gone with this approach, and attached a new patch which fixes it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
From: Peter Eisentraut on 26 Oct 2009 11:53 On sön, 2009-10-25 at 23:48 +0000, Roger Leigh wrote: > Just for reference, this is what the output looks like (abridged) > using the attached patch. Should display fine if your mail client handles > UTF-8 messages correctly: > > rleigh=# \l > List of databases > Name │ Owner │ Encoding │ Collation │ Ctype │ Access privileges > ─────────────────┼──────────┼──────────┼─────────────┼─────────────┼─────────────────────── > merkelpb │ rleigh │ UTF8 │ en_GB.UTF-8 │ en_GB.UTF-8 │ > postgres │ postgres │ UTF8 │ en_GB.UTF-8 │ en_GB.UTF-8 │ > projectb │ rleigh │ UTF8 │ en_GB.UTF-8 │ en_GB.UTF-8 │ > rleigh │ rleigh │ UTF8 │ en_GB.UTF-8 │ en_GB.UTF-8 │ > […] > template0 │ postgres │ UTF8 │ en_GB.UTF-8 │ en_GB.UTF-8 │ =c/postgres ↵ > │ │ │ │ │ postgres=CTc/postgres > template1 │ postgres │ UTF8 │ en_GB.UTF-8 │ en_GB.UTF-8 │ =c/postgres ↵ > │ │ │ │ │ postgres=CTc/postgres > […] > (17 rows) That's pretty much what I had in mind. Cool. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Stark on 26 Oct 2009 13:12 2009/10/25 Roger Leigh <rleigh(a)codelibre.net>: > rleigh=# \l >                   List of databases >    Name    â  Owner  â Encoding â  Collation  â   Ctype   â  Access privileges > ââââââââââââââââââ¼âââââââââââ¼âââââââââââ¼ââââââââââââââ¼ââââââââââââââ¼âââââââââââââââââââââââ >  merkelpb     â rleigh  â UTF8   â en_GB.UTF-8 â en_GB.UTF-8 â >  postgres     â postgres â UTF8   â en_GB.UTF-8 â en_GB.UTF-8 â >  projectb     â rleigh  â UTF8   â en_GB.UTF-8 â en_GB.UTF-8 â >  rleigh      â rleigh  â UTF8   â en_GB.UTF-8 â en_GB.UTF-8 â > [â¦] >  template0    â postgres â UTF8   â en_GB.UTF-8 â en_GB.UTF-8 â =c/postgres      ⵠ>         â      â      â       â       â postgres=CTc/postgres >  template1    â postgres â UTF8   â en_GB.UTF-8 â en_GB.UTF-8 â =c/postgres      ⵠ>         â      â      â       â       â postgres=CTc/postgres > [â¦] > (17 rows) > While i agree this looks nicer I wonder what it does to things like excel/gnumeric/ooffice auto-recognizing table layouts and importing files. I'm not sure our old format was so great for this so maybe this is actually an improvement I'm asking for. But as long as we're changing the format... It would at at least be good to test the behaviour -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 26 Oct 2009 13:33
Greg Stark <gsstark(a)mit.edu> writes: > While i agree this looks nicer I wonder what it does to things like > excel/gnumeric/ooffice auto-recognizing table layouts and importing > files. I'm not sure our old format was so great for this so maybe this > is actually an improvement I'm asking for. Yeah. We can do what we like with the UTF8 format but I'm considerably more worried about the aspect of making random changes to the plain-ASCII output. On the other hand, we changed that just a release or so ago (to put in the multiline output in the first place) and I didn't hear complaints about it that time. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |