On 05/14/2014 12:07 AM, Tom Lane wrote:
Andrew Dunstan <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
