On 05/13/2014 04:14 PM, Tom Lane wrote:
Heikki Linnakangas <hlinnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
