Re: buildfarm / handling (undefined) locales
От | Tom Lane |
---|---|
Тема | Re: buildfarm / handling (undefined) locales |
Дата | |
Msg-id | 25899.1400007515@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | buildfarm / handling (undefined) locales (Tomas Vondra <tv@fuzzy.cz>) |
Ответы |
Re: buildfarm / handling (undefined) locales
(Heikki Linnakangas <hlinnakangas@vmware.com>)
Re: buildfarm / handling (undefined) locales (Tomas Vondra <tv@fuzzy.cz>) Re: buildfarm / handling (undefined) locales (Tomas Vondra <tv@fuzzy.cz>) |
Список | pgsql-hackers |
Tomas Vondra <tv@fuzzy.cz> writes: > a few days ago I switched magpie into an LXC container, and while > fixinig unrelated issue there, I noticed that although the tests seemed > to run, some of the results are actually rubbish because of missing locales. > So for example when the system misses cs_CZ.WIN-1250 (i.e. czech locale > with windows codepage 1250), initdb actually did this > The files belonging to this database system will be owned by user > "pgbuild". > This user must also own the server process. > initdb: invalid locale name "" > initdb: invalid locale name "" > initdb: invalid locale name "" > initdb: invalid locale name "" > initdb: invalid locale name "" > initdb: invalid locale name "" > The database cluster will be initialized with locale "C". > The default database encoding has accordingly been set to > "SQL_ASCII". > The default text search configuration will be set to "english". Hm, I'm a bit confused as to what you actually did here. The "invalid locale name" bleats seem to indicate that no --locale or --lc_xxx options were given on the command line; correct? If so the issue is presumably that the environment variable(s) were set to incorrect values. While we *could* abort in that situation, I've never heard of any program that did; the normal response is to silently ignore the environment variables and use C locale. We're not being exactly silent about it but I think the outcome is the expected one. There is a comment in the code about this: /* should we exit here? */ if (res == NULL) fprintf(stderr, _("%s: invalid locale name \"%s\"\n"), progname, locale); but I think what's being questioned is whether an incorrect locale name *given as a command line argument* should result in an abort. That might be a good idea, but it looks like it'd require some restructuring of the code to make it possible to distinguish the case from bad-environment. > Yeah, not really what we were shooting for. I've fixed this by defining > the missing locales, and indeed - magpie now fails in plpython tests. I saw that earlier today (tho right now the buildfarm server seems to not be responding :-(). Probably we should use some more-widely-used character code in that specific test? regards, tom lane
В списке pgsql-hackers по дате отправления: