Re: garbage in psql -l - Mailing list pgsql-hackers

On Wed, Nov 25, 2009 at 09:39:32AM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > On tis, 2009-11-24 at 14:19 -0500, Tom Lane wrote:
> >> I think you're being overoptimistic to assume that that's going to
> >> eliminate the issue.  It might patch things for Oleg's particular
> >> configuration; but the real problem IMO is that people are depending
> >> on ~/.psqlrc to set encoding/locale related behavior, and that file
> >> isn't read before executing -l/-c (not to mention -X).
>
> > The -l/-c case should probably be fixed.  If the output contains
> > non-ASCII data, then it's not going to display correctly.  Not so much a
> > problem for -l, but definitely for -c, and of course with the Unicode
> > line drawing now in fact also for -l.
>
> I'm not sure that the "fix" won't be worse than the disease here.
> The historical behavior is that .psqlrc isn't read before executing
> -c commands, and I don't find it difficult at all to imagine that
> changing that will break some people's scripts.

The following patch adds in an nl_langinfo(CODESET) check in
addition to the existing client encoding check.  With the
patch applied, unicode table formatting will be enabled only if
these three conditions are met:
 1) The system supports nl_langinfo (i.e. is POSIX/SUS) 2) nl_langinfo reports UTF-8 is the locale codeset 3) The
clientencoding is UTF-8 

This will fix the issue that was reported (in a KOI8-R locale,
the nl_langinfo check will fail).  It will additionally
fix the problem for Microsoft Windows users; since their
systems don't support nl_langinfo,  automatic unicode
support will not be compiled in and so the default will always
be ASCII.

With the patch applied, the only group of users which might
be negatively affected are users with a misconfigured terminal
who additionally meet the above three criteria.  However, the
two primary groups of users for whom this was a genuine bug
(non-UTF-8 locale and Windows) would find this patch should
ensure psql will continue default to ASCII output.  This will
fix the -l/-c problem for them as well.


Regards,
Roger


diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 69d5814..8916ffa 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -21,6 +21,9 @@#endif#include <locale.h>
+#ifdef HAVE_LANGINFO_H
+#include <langinfo.h>
+#endif#include "catalog/pg_type.h"#include "pqsignal.h"
@@ -2552,8 +2555,16 @@ get_line_style(const printTableOpt *opt){    if (opt->line_style != NULL)        return
opt->line_style;
-    else if (opt->encoding == pg_get_utf8_id())
+#if (defined(HAVE_LANGINFO_H) && defined(CODESET))
+    /* If a UTF-8 locale is available, and the client encoding is
+     * also UTF-8, switch to UTF-8 box drawing characters
+     */
+    else if ((pg_strcasecmp(nl_langinfo(CODESET), "UTF-8") == 0 ||
+          pg_strcasecmp(nl_langinfo(CODESET), "utf8") == 0 ||
+          pg_strcasecmp(nl_langinfo(CODESET), "CP65001") == 0) &&
+         opt->encoding == pg_get_utf8_id())        return &pg_utf8format;
+#endif    else        return &pg_asciiformat;}

--  .''`.  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.