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 30 Sep 2009 17:32 Peter Eisentraut <peter_e(a)gmx.net> writes: > On Wed, 2009-09-30 at 14:02 -0400, Alvaro Herrera wrote: >> All scripts I've seen parsing psql output use unaligned, undecorated >> mode. I have yet to see one messing with the |'s. > Plus, we would have broken that with the : continuation lines. Only for data containing embedded newlines, which is not that common. 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: Tom Lane on 30 Sep 2009 18:50 Roger Leigh <rleigh(a)codelibre.net> writes: >> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote: >>> Thinking about this some more, ISTM a much better way of approaching >>> it would be to provide a flag for psql to turn off the fancy >>> formatting, and have pg_regress use that flag. > The attached patch implements this feature. It adds a > --no-pretty-formatting/-G option to psql (naming isn't my fort�, > so feel free to change it!). This is also documented in the > SGML docs, and help text. Lastly, this option is used when invoking > psql by pg_regress, which results in a working testsuite in a UTF-8 > locale. It would be a good idea to tie this to a psql magic variable (like ON_ERROR_STOP) so that it could conveniently be set in ~/.psqlrc. I'm not actually sure that we need a dedicated command line switch for it, since you could use "-v varname" instead. 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: Peter Eisentraut on 1 Oct 2009 00:17 On Wed, 2009-09-30 at 18:50 -0400, Tom Lane wrote: > It would be a good idea to tie this to a psql magic variable (like > ON_ERROR_STOP) so that it could conveniently be set in ~/.psqlrc. > I'm not actually sure that we need a dedicated command line switch > for it, since you could use "-v varname" instead. Right. A better yet place would be inside \pset, since that contains the other formatting options. -- 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 2 Oct 2009 07:21 On Wed, Sep 30, 2009 at 06:50:46PM -0400, Tom Lane wrote: > Roger Leigh <rleigh(a)codelibre.net> writes: > >> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote: > >>> Thinking about this some more, ISTM a much better way of approaching > >>> it would be to provide a flag for psql to turn off the fancy > >>> formatting, and have pg_regress use that flag. > > > The attached patch implements this feature. It adds a > > --no-pretty-formatting/-G option to psql (naming isn't my fort�, > > so feel free to change it!). This is also documented in the > > SGML docs, and help text. Lastly, this option is used when invoking > > psql by pg_regress, which results in a working testsuite in a UTF-8 > > locale. > > It would be a good idea to tie this to a psql magic variable (like > ON_ERROR_STOP) so that it could conveniently be set in ~/.psqlrc. > I'm not actually sure that we need a dedicated command line switch > for it, since you could use "-v varname" instead. I have attached a patch which implements the feature as a pset variable. This also slightly simplifies some of the patch since the table style is passed to functions directly in printTableContent rather than separately. The psql option '-P tablestyle=ascii' is passed to psql in pg_regress_main.c which means the testsuite doesn't fail any more. The option is documented in the psql docs, and is also tab-completed. Users can just put '\pset tablestyle ascii' in their .psqlrc if they want the old format in a UTF-8 locale. To follow up on the comments about the problems of defaulting to UTF-8. There are just two potential problems with defaulting, both of which are problems with the user's mis-configuration of their system and (IMHO) not something that postgresql needs to care about. 1) The user lacks a font containing the line-drawing characters. It's very rare for a fixed-width terminal font to not contain these characters, and the patch as provided sticks to the most basic range from the VT100 set which are most commonly provided. 2) The user's terminal emulator is not configured to accept UTF-8 input. If you're using a UTF-8 locale, then this is necessary to display non-ASCII characters, and is done automatically by almost every terminal emulator out there (on Linux, they default to using nl_langinfo(CODESET) unless configured otherwise, which is a very simple change if required). On any current GNU/Linux system, you have to go out of your way to break the defaults. The patch currently switches to UTF-8 automatically /when available/. IMO this is the correct behaviour since it will work for all but the handful of users who misconfigured their system, and provides an immediate benefit. We spent years making UTF-8 work out of the box on Linux and Unix systems, and it seems a trifle unfair to penalise all users for the sake of the few who just didn't set up their terminal emulator correctly (their setup is already broken, since non-ASCII characters returned by queries are /already/ going to be displayed incorrectly). 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: "Brad T. Sliger" on 2 Oct 2009 20:34
On Friday 02 October 2009 04:21:35 Roger Leigh wrote: > On Wed, Sep 30, 2009 at 06:50:46PM -0400, Tom Lane wrote: > > Roger Leigh <rleigh(a)codelibre.net> writes: > > >> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote: > > >>> Thinking about this some more, ISTM a much better way of approaching > > >>> it would be to provide a flag for psql to turn off the fancy > > >>> formatting, and have pg_regress use that flag. > > > > > > The attached patch implements this feature. It adds a > > > --no-pretty-formatting/-G option to psql (naming isn't my forté, > > > so feel free to change it!). This is also documented in the > > > SGML docs, and help text. Lastly, this option is used when invoking > > > psql by pg_regress, which results in a working testsuite in a UTF-8 > > > locale. > > > > It would be a good idea to tie this to a psql magic variable (like > > ON_ERROR_STOP) so that it could conveniently be set in ~/.psqlrc. > > I'm not actually sure that we need a dedicated command line switch > > for it, since you could use "-v varname" instead. > > I have attached a patch which implements the feature as a pset > variable. This also slightly simplifies some of the patch since > the table style is passed to functions directly in printTableContent > rather than separately. The psql option '-P tablestyle=ascii' is > passed to psql in pg_regress_main.c which means the testsuite doesn't > fail any more. The option is documented in the psql docs, and is > also tab-completed. Users can just put '\pset tablestyle ascii' in > their .psqlrc if they want the old format in a UTF-8 locale. > > To follow up on the comments about the problems of defaulting to > UTF-8. There are just two potential problems with defaulting, both of > which are problems with the user's mis-configuration of their system > and (IMHO) not something that postgresql needs to care about. > 1) The user lacks a font containing the line-drawing characters. > It's very rare for a fixed-width terminal font to not contain > these characters, and the patch as provided sticks to the most > basic range from the VT100 set which are most commonly provided. > 2) The user's terminal emulator is not configured to accept UTF-8 > input. If you're using a UTF-8 locale, then this is necessary > to display non-ASCII characters, and is done automatically by > almost every terminal emulator out there (on Linux, they default > to using nl_langinfo(CODESET) unless configured otherwise, which > is a very simple change if required). On any current GNU/Linux > system, you have to go out of your way to break the defaults. > > The patch currently switches to UTF-8 automatically /when available/. > IMO this is the correct behaviour since it will work for all but the > handful of users who misconfigured their system, and provides an > immediate benefit. We spent years making UTF-8 work out of the box on > Linux and Unix systems, and it seems a trifle unfair to penalise all > users for the sake of the few who just didn't set up their terminal > emulator correctly (their setup is already broken, since non-ASCII > characters returned by queries are /already/ going to be displayed > incorrectly). > > > Regards, > Roger I looked at psql-utf8-table-5.patch. Lint(1) says there is an extra trailing ',' in src/bin/psql/print.h. in 'typedef enum printTextRule'. The addition to src/bin/psql/command.c could use a comment, like adjacent code. 'ASCII' and 'UTF8' may need <acronym></acronym> tags in doc/src/sgml/ref/psql-ref.sgml, like adjacent code. I'm not sure someone who hasn't seen this patch in action would immediately know what it does from the documentation. `gmake html` works without the patch, but fails with the patch: openjade:ref/psql-ref.sgml:1692:15:E: document type does not allow element "TERM" here; assuming missing "VARLISTENTRY" start-tag After the patch, `\pset format wrapped` produces '\pset: unknown option: format'. I saw this in interactive psql and from .psqlrc. I think this can be fixed by changing the addition to src/bin/psql/command.c from an 'if' clause to an 'else if' clause. Otherwise, the patch applied, built and installed. The `gmake check` tests all passed with LANG and/or LC_ALL set. The various tablestyle options seem to work. The default behavior with respect to various LANG and LC_ALL values seems reasonable and can be overridden. Thanks, --bts -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |