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

From Tom Lane
Subject Re: PATCH: CITEXT 2.0 v3
Date
Msg-id 29758.1216061346@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:
> On Jul 14, 2008, at 11:06, Tom Lane wrote:
>> Let me put it another way: if we test on another platform and find out
>> that strcoll's behavior is different there, are you going to fix that
>> version of strcoll?  No, you're not.  So you might as well just test  
>> the
>> behavior of the code that's actually under your control.

> You don't seem to understand what I'm suggesting: I'm not talking  
> about testing strcoll. I'm talking about making sure that citext  
> *uses* strcoll.

This seems pointless, as well as essentially impossible to enforce by
black-box testing.  Nobody is likely to consider a patch that removes
such obviously basic functionality of the module.  I think you're
worrying about testing the wrong things --- and as evidence I'd note the
serious errors that slipped by your testing (including the fact that the
last submitted version would still claim that 'a' = 'ab').  What we
generally ask a regression test to do is catch portability problems
(which is certainly a real-enough issue here, but we don't know how
to address it well) or catch foreseeable breakage (such as someone
introducing a cast that breaks resolution of citext function calls).
The methodology can't catch everything, and trying to push it beyond
what it can do is just a time sink for effort that can more usefully
be spent other ways, such as code-reading.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fwd: Proposal - UUID data type
Next
From: "David E. Wheeler"
Date:
Subject: Re: PATCH: CITEXT 2.0 v3