On 05/13/2014 04:14 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
>> On 05/13/2014 09:58 PM, Tom Lane wrote:
>>> ... 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.
>> Initdb isn't like most programs. The locale given to initdb is memorized
>> in the data directory, and if you later notice that it was wrong, you'll
>> have to dump and reload. There is a strong argument for initdb to be
>> more strict than, say, your average text editor.
> Hm, well, if that's the behavior we want then it's certainly an easy
> change.
>
> 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.
cheers
andrew
