Re: foreign_data test fails with non-C locale

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> This called for an extensive test ... :-)

> My glibc installation supplies 668 locales (locale -a), which appear to
> represent about 225 distinct language/country combinations. (The rest are
> encoding variants.)

> I ran the regression tests with all of them, and got 95 failures (out of 668).

Fascinating data. I assume you did not remove the existing
locale-variant expected files? IOW this isn't "all the locale
dependencies", but "all the ones we didn't fix previously"?

> We could easily get rid of the aa, ch, and v/w failures by adjusting the test
> data, since the data is completely coincidental anyway. I propose to do
> that, and document these issues so that they can be avoided in future tests.

I have no confidence in the ability of some documentation to keep the
tests clean. However, if we had buildfarm members testing in locales
that exercise each of those cases, it'd be all right.

If we try to fix those cases I think we should try to fix Turkish i
as well ... but I concur that first requires determining if it's
behaving wrong or not. Devrim, or someone?

> Also, considering that some of these alternative sorting rules appear to be
> controversial even among users of the language (e.g., we have had actual bug
> reports that the es_EC rule is wrong, and the sv_SE rule is also obsolete
> according to the language regulators), it might be interesting to write a
> small test program that can tell users how their current locale behaves in
> known corner cases.

Considering the number of people who complain about en_US (expecting C
sort order instead), I'm not sure you should consider this a corner
case.

regards, tom lane