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 15:04 On Tue, 2009-09-29 at 12:01 -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. (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. -- 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 16:28 Peter Eisentraut <peter_e(a)gmx.net> writes: > On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote: >> 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. Well, that seems fairly reasonable, but it's going to require some refactoring of pg_regress. The initialize_environment function determines what happens in both the client and the temp server. 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: Tom Lane on 29 Sep 2009 16:32 Roger Leigh <rleigh(a)codelibre.net> writes: >> 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 really, really don't believe that that meets either the letter or the spirit of the C standard, at least not if you are intending to silently substitute LC_CTYPE=UTF8 when the program has specified C/POSIX locale. (If this is just a matter of what the default LANG environment is, of course you can do anything.) 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: Robert Haas on 29 Sep 2009 18:30 On Tue, Sep 29, 2009 at 4:28 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e(a)gmx.net> writes: >> On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote: >>> 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. > > Well, that seems fairly reasonable, but it's going to require some > refactoring of pg_regress. The initialize_environment function > determines what happens in both the client and the temp server. This seems to mean that we can't apply this patch, since failing the regression tests is not an acceptable behavior. I think that means that the patch author needs to either do the necessary pg_regress refactoring or figure out some other solution that is acceptable to the community. Assuming that non-trivial pg_regress refactoring is required, I think we should mark this patch as Returned with Feedback, because that should really be a separate patch, and it's obviously far too late to submit new patches to this CommitFest. Objections? ....Robert -- 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: Alvaro Herrera on 29 Sep 2009 18:33
Robert Haas escribi�: > On Tue, Sep 29, 2009 at 4:28 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > Peter Eisentraut <peter_e(a)gmx.net> writes: > >> On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote: > >>> 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. > > > > Well, that seems fairly reasonable, but it's going to require some > > refactoring of pg_regress. �The initialize_environment function > > determines what happens in both the client and the temp server. > > This seems to mean that we can't apply this patch, since failing the > regression tests is not an acceptable behavior. I think that means > that the patch author needs to either do the necessary pg_regress > refactoring or figure out some other solution that is acceptable to > the community. Assuming that non-trivial pg_regress refactoring is > required, I think we should mark this patch as Returned with Feedback, > because that should really be a separate patch, and it's obviously far > too late to submit new patches to this CommitFest. > > Objections? Does the patch pass regression tests in normal conditions? If it does, I see no reason to reject it. If it fails in --locale only, and even then only when the given locale is UTF8, which IIRC it's a seldom-used case, we can see about fixing that separately. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |