Re: PATCH: CITEXT 2.0 v3 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PATCH: CITEXT 2.0 v3
Date
Msg-id 7889.1216045490@sss.pgh.pa.us
Whole thread Raw
In response to Re: PATCH: CITEXT 2.0 v3  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: PATCH: CITEXT 2.0 v3  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
"David E. Wheeler" <david@kineticode.com> writes:
> Could I supply two comparison files, one for Mac OS X with en_US.UTF-8  
> and one for everything else, as described in the last three paragraphs  
> here?

The fallacy in that proposal is the assumption that there are only two
behaviors out there.  Let me recalibrate your thoughts a bit: so far
I have tried citext on three different machines (Mac, Fedora 8, HPUX),
and I got three different answers from those tests.  That's despite
endeavoring to make the database locales match ... which is less than
trivial in itself because they use three slightly different spellings of
"en_US.UTF8".

Given that you were more or less deliberately testing corner cases,
I think it's quite likely that the number of observable reactions from
N platforms would be more nearly O(N) than O(1).

In the real world, to the extent that we are able to control the locale
of the regression tests, we make it "C" --- and to a large extent we
can't control it at all, which means you have another uncontrolled
variable besides platform.  So in the current universe there is
absolutely no value in submitting locale-specific tests for a contrib
module.

I see some discussion in the thread about improving the situation, but
until we are able to decouple database locale from environment locale,
I doubt we'll be able to do a whole lot about automating this kind
of test.  There are too many variables at the moment.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PATCH: CITEXT 2.0 v3
Next
From: Tom Lane
Date:
Subject: Re: PATCH: CITEXT 2.0 v3