I have a comment on this bit: > @@ -125,6 +128,17 @@ main(int argc, char *argv[]) > > /* We rely on unmentioned fields of pset.popt to start out > 0/false/NULL */ > pset.popt.topt.format = PRINT_ALIGNED; > + > + /* Default table style to plain ASCII */ > + pset.popt.topt.table_style = &asciiformat; > +#if (defined(HAVE_LANGINFO_H) && defined(CODESET)) > + /* If a UTF-8 locale is available, switch to UTF-8 box drawing > characters */ > + if (pg_strcasecmp(nl_langinfo(CODESET), "UTF-8") == 0 || > + pg_strcasecmp(nl_langinfo(CODESET), "utf8") == 0 || > + pg_strcasecmp(nl_langinfo(CODESET), "CP65001") == 0) > + pset.popt.topt.table_style = &utf8format; > +#endif > + > pset.popt.topt.border = 1; > pset.popt.topt.pager = 1; > pset.popt.topt.start_table = true;
Elsewhere in the psql code, notably in mbprint.c, we make the decision on whether to apply certain Unicode-aware processing based on whether the client encoding is UTF8. The same should be done here. There is a patch somewhere in the pipeline that would automatically set the psql client encoding to whatever the locale says, but until that is done, the client encoding should be the sole setting that rules what kind of character set processing is done on the client side. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
