On 05/14/2014 12:07 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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.
Printing the values of the environment variables sounds complicated, but
I think a generic hint along these lines would be good:
$ 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
HINT: This usually means that the LANG, LC_ALL or LC_* environment
variable has an invalid value.
Specifically mentioning those environment variables by name would be
very helpful to the user. They are specified by POSIX:
http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html, so they're
not that platform-specific. Windows is a different story, though.
- Heikki