From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Getting the red out (of the buildfarm) |
Date: | 2009-10-03 16:20:02 |
Message-ID: | 1378.1254586802@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Sat, 2009-10-03 at 11:21 -0400, Tom Lane wrote:
>> Where exactly are you expecting the latter string to get
>> substituted in?
> The way I understand it, the \uxxxx comes from psql, mbprint.c. So this
> may depend on exactly what locale psql, as run by pg_regress, thinks it
> is in.
[ looks at psql code ... ] Ah, I think actually the key question is
what the client_encoding is. It looks to me like the \u0080 is only
likely to come out if psql is working in utf8 encoding. In particular,
in LATIN2 it is *guaranteed* to think that 0x80 is a displayable
character, because wchar.c will tell it so (look at pg_latin1_dsplen).
So plpython_unicode.out is in fact assuming UTF8 encoding is used.
The results from the _moth buildfarm machines suggest that the
prevailing locale is something Windows-ish, or maybe that's just an
artifact introduced somewhere between the actual test and the web page.
I am inclined to think that we should add another expected-file
showing the single-byte \200 result. What that might get displayed
as on the local system isn't really our concern.
Alternatively, maybe we should change pg_latin1_dsplen so that it
reports 0x80-0x9F as control characters; but that would have
consequences far beyond this one regression test.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-10-03 17:37:37 | Re: Getting the red out (of the buildfarm) |
Previous Message | Peter Eisentraut | 2009-10-03 15:38:47 | Re: Getting the red out (of the buildfarm) |