Re: buildfarm / handling (undefined) locales

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