Re: buildfarm / handling (undefined) locales

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 05/13/2014 04:14 PM, Tom Lane wrote:
>> But independently of whether it's a fatal error or not: when there's
>> no relevant command-line argument then we print the
>>
>> invalid locale name ""
>>
>> message which is surely pretty unhelpful. It'd be better if we could
>> finger the incorrect environment setting. Unfortunately, we don't know
>> for sure which environment variable(s) setlocale was looking at --- I
>> believe it's somewhat platform specific. We could probably print
>> something like this instead:
>>
>> environment locale settings are invalid
>>
>> Thoughts?

> I'd also be tempted to add the settings for LC_ALL and LANG and note
> that they are possible sources of the problem, or maybe only do that if
> they match the locale being rejected.

Well, all we know is that we asked setlocale for the default locale from
the environment and it failed. We don't really know which variable(s)
it looked at. I think printing specific variables could easily be as
misleading as it is helpful; and given the lack of prior complaints,
I'm doubtful that it's worth going to the effort of trying to print a
platform-specific collection of variables.

Attached is a draft patch that behaves like this:

$ initdb --locale=foo
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

initdb: invalid locale name "foo"

$ LANG=foo initdb
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

initdb: environment locale settings are invalid

Most of the bulk of the patch is getting rid of the no-longer-useful
boolean result of check_locale_name.

regards, tom lane