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
