Unicode UTF-8 table formatting for psql text output
in [PgSql]
|
Prev: Hot Standby 0.2.1
Next: Rejecting weak passwords
From: Peter Eisentraut on 29 Sep 2009 10:21 On Mon, 2009-09-28 at 20:49 -0700, Brad T. Sliger wrote: > During this review I found that `gmake check` will fail when > LANG=en_US.UTF-8 in the environment. In this case > the patched psql produces UTF8 line art and the tests expect ASCII > line art. > > pg_regress clears LC_ALL by default, but does not clear LANG > by default. Please find attached a patch that > causes pg_regress to also clear LANG by default. It probably doesn't matter much, but I think the proper fix would be to unset LC_CTYPE. -- 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 29 Sep 2009 12:01 Peter Eisentraut <peter_e(a)gmx.net> writes: > On Mon, 2009-09-28 at 20:49 -0700, Brad T. Sliger wrote: >> pg_regress clears LC_ALL by default, but does not clear LANG >> by default. Please find attached a patch that >> causes pg_regress to also clear LANG by default. > It probably doesn't matter much, but I think the proper fix would be to > unset LC_CTYPE. Wouldn't we have to clear *all* of these variables to be sure? The bigger question is exactly how we expect this stuff to interact with pg_regress' --no-locale switch. We already do clear all these variables when --no-locale is specified. I am wondering just what --locale is supposed to do, and whether selectively lobotomizing the LC stuff has any real use at all. 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 29 Sep 2009 13:13 On Tue, Sep 29, 2009 at 12:01:30PM -0400, Tom Lane wrote: > Peter Eisentraut <peter_e(a)gmx.net> writes: > > On Mon, 2009-09-28 at 20:49 -0700, Brad T. Sliger wrote: > >> pg_regress clears LC_ALL by default, but does not clear LANG > >> by default. Please find attached a patch that > >> causes pg_regress to also clear LANG by default. > > > It probably doesn't matter much, but I think the proper fix would be to > > unset LC_CTYPE. > > Wouldn't we have to clear *all* of these variables to be sure? > > The bigger question is exactly how we expect this stuff to interact with > pg_regress' --no-locale switch. We already do clear all these variables > when --no-locale is specified. I am wondering just what --locale is > supposed to do, and whether selectively lobotomizing the LC stuff has > any real use at all. While this is currently just hypothetical, the code is also making the assumption that the C locale is ASCII. However, there is no guarantee that this is the case. ASCII is the minimal requirement, and UTF-8 is a superset (according to SUS/POSIX). In Debian, we do have plans to introduce a C.UTF-8 locale, and perhaps eventually move the C locale to using UTF-8 by default, at which point the tests would again fail because you would still get the UTF-8 formatting despite all of the LC_ etc. munging. (At that point, we would have a C.ASCII for compatibility.) 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. -- 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 29 Sep 2009 13:41 Roger Leigh <rleigh(a)codelibre.net> writes: > In Debian, we do have plans to introduce a C.UTF-8 locale, Egad, isn't that a contradiction in terms? C locale means POSIX behavior and nothing but. 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 29 Sep 2009 14:25
On Tue, Sep 29, 2009 at 01:41:27PM -0400, Tom Lane wrote: > Roger Leigh <rleigh(a)codelibre.net> writes: > > In Debian, we do have plans to introduce a C.UTF-8 locale, > > Egad, isn't that a contradiction in terms? Not entirely! > C locale means POSIX behavior and nothing but. Indeed it does. However, making LC_CTYPE be UTF-8 rather than ASCII is both possible and still strictly conforming to the letter of the standard. There would be some collation and other restrictions ("digit" and other character classes would be contrained to the ASCII characters compared with other UTF-8 locales). However, any existing programs using ASCII would continue to function without any changes to their behaviour. The only observable change will be that nl_langinfo(CODESET) will return UTF-8, and it will be valid for programs to use UTF-8 encoded text in formatted print functions, etc.. I'd just like to stress that this isn't happening anytime soon! (Well, C.UTF-8 is possible now, it's just not hardcoded into libc.so. The intention is to initially provide C.UTF-8 in addition to C so that programs requiring UTF-8 support have a locale guaranteed to be present on the system to meet their needs.) 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |