Re: buildfarm / handling (undefined) locales - Mailing list pgsql-hackers

From Tom Lane
Subject Re: buildfarm / handling (undefined) locales
Date
Msg-id 27525.1400012096@sss.pgh.pa.us
Whole thread Raw
In response to Re: buildfarm / handling (undefined) locales  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: buildfarm / handling (undefined) locales
Re: buildfarm / handling (undefined) locales
List pgsql-hackers
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?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: buildfarm / handling (undefined) locales
Next
From: Andrew Dunstan
Date:
Subject: Re: buildfarm / handling (undefined) locales