Re: Getting the red out (of the buildfarm)

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

In response to

Responses

Browse pgsql-hackers by date

  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)