Unicode UTF-8 table formatting for psql text output
in [PgSql]
|
Prev: Hot Standby 0.2.1
Next: Rejecting weak passwords
From: Tom Lane on 13 Oct 2009 17:08 Roger Leigh <rleigh(a)codelibre.net> writes: > The attached updated patch renames all user-visible uses of > "utf8" to "unicode". It also updates the documentation > regarding "locale" to "psql client character set encoding" > so the docs now match the code exactly. Applied with light editorialization. The main non-cosmetic change I made was to postpone selection of default line_style until runtime (see get_line_style() in the committed patch). The original coding required knowledge of the line_style default rule not only in three different places in psql, but in every other place using print.c, such as createlang/droplang -l (which dumped core with the patch as submitted). I changed it so that leaving line_style NULL implies the default encoding-driven behavior, so that we don't need to touch any of the callers. 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
From: Roger Leigh on 14 Oct 2009 10:59 On Tue, Oct 13, 2009 at 05:08:20PM -0400, Tom Lane wrote: > Roger Leigh <rleigh(a)codelibre.net> writes: > > The attached updated patch renames all user-visible uses of > > "utf8" to "unicode". It also updates the documentation > > regarding "locale" to "psql client character set encoding" > > so the docs now match the code exactly. > > Applied with light editorialization. The main non-cosmetic change > I made was to postpone selection of default line_style until runtime > (see get_line_style() in the committed patch). The original coding > required knowledge of the line_style default rule not only in three > different places in psql, but in every other place using print.c, > such as createlang/droplang -l (which dumped core with the patch as > submitted). I changed it so that leaving line_style NULL implies > the default encoding-driven behavior, so that we don't need to touch > any of the callers. Thanks. I agree with your improvement in get_line_style(), it's cleaner this way; I didn't realise print.c was used by the other programs, sorry about that. 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 16 Oct 2009 06:38 (HTML mail to preserve formatting; let's see if it works.) 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) 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. On a side note, I don't really understand why the access privileges need to be broken up over multiple lines. There is plenty of space left on the line. Note that the above is close to a default setup, so that is what many people will see by default from now on.
From: Roger Leigh on 16 Oct 2009 07:52 On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote: > (HTML mail to preserve formatting; let's see if it works.) > > I like the new Unicode tables, but the marking of continuation lines > looks pretty horrible: Yes, I'm not so keen myself. The ASCII characters used are '|', ':' and ' ' for normal, wrapped and newlines. Here, we are using vertical lines with two or three dashes to replace the latter two. As mentioned earlier in the thread, this patch will be followed up with a futher patch to unify the folding/newline behaviour between column header and data lines, which will replace these with normal vertical lines in all cases, with the addition of characters in the margin such as as a CR symbol or ellipsis to indicate newlines or wrapping. To preserve backward compatibility, the ASCII output will remain unchanged. I would have done this in the patch as applied, but was asked to hold off doing that until the initial work was committed. > Note that the above is close to a default setup, so that is what many > people will see by default from now on. I'll try to get the above proposed change done in the next week or so, in time for the next CommitFest, if you agree with the general idea. 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 24 Oct 2009 13:23
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) > > 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. This patch does break backward compatibility with older psql versions, by using symbols in the column border to mark newlines and wrapped lines rather than putting ':' and ';' and ' ' symbols in the vertical table lines. This makes things somewhat more consistent and readable but at the expense of not perfectly preserving output. The ASCII rules are a little more compatible than the Unicode rules, but both do break things a little. If the data lines do not contain either newlines or wrapped text, then the output will remain unchanged. Any feedback would be appreciated. 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. |