From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: buildfarm / handling (undefined) locales |
Date: | 2014-05-13 18:58:35 |
Message-ID: | 25899.1400007515@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Vondra <tv(at)fuzzy(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-05-13 19:03:16 | Re: buildfarm / handling (undefined) locales |
Previous Message | Tomas Vondra | 2014-05-13 18:42:16 | Re: Sending out a request for more buildfarm animals? |