Andrew Dunstan <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
