Re: Unicode UTF-8 table formatting for psql text output
От | Peter Eisentraut |
---|---|
Тема | Re: Unicode UTF-8 table formatting for psql text output |
Дата | |
Msg-id | 1254251082.9276.2.camel@vanquo.pezone.net обсуждение исходный текст |
Ответ на | Re: Unicode UTF-8 table formatting for psql text output (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Unicode UTF-8 table formatting for psql text output
|
Список | pgsql-hackers |
On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote: > Peter Eisentraut <peter_e@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. (Actually, I should have said, set LC_CTYPE to C.) > Wouldn't we have to clear *all* of these variables to be sure? Not really. The problem here is that psql checks whether the console uses UTF8, and that is controlled by the LC_CTYPE variable on Unix-ish systems. > 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. We should do the LANG or LC_CTYPE thing only on the client, unconditionally. The --no-locale/--locale options should primarily determine what the temporary server uses.
В списке pgsql-hackers по дате отправления: