Re: force C locale for temp regression installations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: force C locale for temp regression installations
Date: 2005-08-26 16:33:48
Message-ID: 9865.1125074028@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Both Petr and I have seen that with --no-locale set the regression set
> gets a clean run. If you want us to dig deeper into those 9 failures,
> just tell us what to look for.

Well, for example, the first diff in the opr_sanity test appears to
indicate that 'abstime_timestamptz'::text is equal to
'abstime_timestamp'::text (because it is claiming to have joined two
pg_proc rows with those prosrc values). I don't care *what* locale
you're using, that is a wrong answer.

There are some pretty bogus-looking results in the union test, as well,
implying that it thinks 'abcd' is not equal to 'abcd' for instance.

And why did it suddenly start failing today? My bet is those UTF8/UTF16
routines we put in are a few bricks shy of a load yet, and that
--no-locale "fixes" it by preventing those routines from being used.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2005-08-26 16:34:28 Re: force C locale for temp regression installations
Previous Message Petr Jelinek 2005-08-26 16:29:20 Re: force C locale for temp regression installations