Re: Unicode UTF-8 table formatting for psql text output - Mailing list pgsql-hackers

On Wed, Sep 30, 2009 at 06:50:46PM -0400, Tom Lane wrote:
> Roger Leigh <rleigh@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.