Re: force C locale for temp regression installations - Mailing list pgsql-patches

From Tom Lane
Subject Re: force C locale for temp regression installations
Date
Msg-id 9865.1125074028@sss.pgh.pa.us
Whole thread Raw
In response to Re: force C locale for temp regression installations  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: force C locale for temp regression installations  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-patches
Andrew Dunstan <andrew@dunslane.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

pgsql-patches by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: force C locale for temp regression installations
Next
From: Andrew Dunstan
Date:
Subject: Re: force C locale for temp regression installations