I wrote:
> Andrew Dunstan writes:
>> Let's just stick to ASCII.
> The more I think about it, the more I think that using a plain-ASCII
> character would defeat most of the purpose of the test. Non-breaking
> space seems like the best bet here, not least because it has several
> different represe
Andrew Dunstan writes:
> On 06/01/2014 05:35 PM, Tom Lane wrote:
>> I did a little bit of experimentation and determined that none of the
>> LATIN1 characters are significantly more portable than what we've got:
>> for instance a-acute fails to convert into 16 of the 33 supported
>> server-side en
On 06/01/2014 05:35 PM, Tom Lane wrote:
I wrote:
3. Try to select some "more portable" non-ASCII character, perhaps U+00A0
(non breaking space) or U+00E1 (a-acute). I think this would probably
work for most encodings but it might still fail in the Far East. Another
objection is that the expec
I wrote:
> 3. Try to select some "more portable" non-ASCII character, perhaps U+00A0
> (non breaking space) or U+00E1 (a-acute). I think this would probably
> work for most encodings but it might still fail in the Far East. Another
> objection is that the expected/plpython_unicode.out file would
Tomas Vondra writes:
> On 13.5.2014 20:58, Tom Lane wrote:
>> Tomas Vondra writes:
>>> Yeah, not really what we were shooting for. I've fixed this by
>>> defining the missing locales, and indeed - magpie now fails in
>>> plpython tests.
>> I saw that earlier today (tho right now the buildfarm se
On 13.5.2014 20:58, Tom Lane wrote:
> Tomas Vondra writes:
>> Yeah, not really what we were shooting for. I've fixed this by
>> defining the missing locales, and indeed - magpie now fails in
>> plpython tests.
>
> I saw that earlier today (tho right now the buildfarm server seems
> to not be res
Tomas Vondra writes:
> On 13.5.2014 23:07, Tom Lane wrote:
>> Attached is a draft patch that behaves like this:
>>
>> $ initdb --locale=foo
>> The files belonging to this database system will be owned by user "postgres".
>> This user must also own the server process.
>>
>> initdb: invalid locale
On 13.5.2014 23:07, Tom Lane wrote:
> Andrew Dunstan 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 pr
On 05/14/2014 11:02 AM, Tom Lane wrote:
I wrote:
As far as Windows goes, we could certainly use #ifdef WIN32 to print
some different text, if anyone can write down what it should be.
Some googling suggests that on Windows, setlocale pays no attention
to environment variables but gets a value t
I wrote:
> As far as Windows goes, we could certainly use #ifdef WIN32 to print
> some different text, if anyone can write down what it should be.
Some googling suggests that on Windows, setlocale pays no attention
to environment variables but gets a value that the user can set via
the Control Pan
On 14 Květen 2014, 16:26, Heikki Linnakangas wrote:
> On 05/14/2014 05:19 PM, Tom Lane wrote:
>
>> Anyway, given that we seem to have consensus on doing this (modulo
>> exact text of the error message), the next question is whether we
>> want to change this only in HEAD, or consider it a back-patch
On 05/14/2014 05:19 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 05/14/2014 12:07 AM, Tom Lane wrote:
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.
Printing the values of the
Heikki Linnakangas writes:
> On 05/14/2014 12:07 AM, Tom Lane wrote:
>> 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.
> Printing the values of the environment variables sounds com
On 05/14/2014 12:07 AM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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
On 05/13/2014 04:14 PM, Tom Lane wrote:
Heikki Linnakangas 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
Re: Tom Lane 2014-05-13 <27525.1400012...@sss.pgh.pa.us>
> Heikki Linnakangas 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 he
On 05/13/2014 03:40 PM, Tom Lane wrote:
Tomas Vondra writes:
On 13.5.2014 21:03, Andrew Dunstan wrote:
On 05/13/2014 02:39 PM, Tomas Vondra wrote:
However in the lastrun-logs I see 81 files, and upon closer inspection
it seems that pretty much logs for all custom locales (cs_CZ.*, sk_SK.*)
a
Heikki Linnakangas 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
On 13.5.2014 20:58, Tom Lane wrote:
> Tomas Vondra writes:
>> a few days ago I switched magpie into an LXC container, and while
>> fixinig unrelated issue there, I noticed that although the tests seemed
>> to run, some of the results are actually rubbish because of missing locales.
>
>> So for ex
On 05/13/2014 09:58 PM, Tom Lane wrote:
Tomas Vondra writes:
a few days ago I switched magpie into an LXC container, and while
fixinig unrelated issue there, I noticed that although the tests seemed
to run, some of the results are actually rubbish because of missing locales.
So for example w
Tomas Vondra writes:
> On 13.5.2014 21:03, Andrew Dunstan wrote:
>> On 05/13/2014 02:39 PM, Tomas Vondra wrote:
>>> However in the lastrun-logs I see 81 files, and upon closer inspection
>>> it seems that pretty much logs for all custom locales (cs_CZ.*, sk_SK.*)
>>> are missing:
>> Clearly this
On 13.5.2014 21:03, Andrew Dunstan wrote:
>
> On 05/13/2014 02:39 PM, Tomas Vondra wrote:
>> On 13.5.2014 20:27, Tomas Vondra wrote:
>>> Hi all,
>>>
>>> a few days ago I switched magpie into an LXC container, and while
>>> fixinig unrelated issue there, I noticed that although the tests seemed
>>>
On 05/13/2014 02:39 PM, Tomas Vondra wrote:
On 13.5.2014 20:27, Tomas Vondra wrote:
Hi all,
a few days ago I switched magpie into an LXC container, and while
fixinig unrelated issue there, I noticed that although the tests seemed
to run, some of the results are actually rubbish because of miss
Tomas Vondra writes:
> a few days ago I switched magpie into an LXC container, and while
> fixinig unrelated issue there, I noticed that although the tests seemed
> to run, some of the results are actually rubbish because of missing locales.
> So for example when the system misses cs_CZ.WIN-1250
On 13.5.2014 20:27, Tomas Vondra wrote:
> Hi all,
>
> a few days ago I switched magpie into an LXC container, and while
> fixinig unrelated issue there, I noticed that although the tests seemed
> to run, some of the results are actually rubbish because of missing locales.
I forgot to mention that
Hi all,
a few days ago I switched magpie into an LXC container, and while
fixinig unrelated issue there, I noticed that although the tests seemed
to run, some of the results are actually rubbish because of missing locales.
So for example when the system misses cs_CZ.WIN-1250 (i.e. czech locale
wi
27 matches
Mail list logo
