Re: PATCH: CITEXT 2.0 v3

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PATCH: CITEXT 2.0 v3
Дата
Msg-id 29758.1216061346@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PATCH: CITEXT 2.0 v3  ("David E. Wheeler" <david@kineticode.com>)
Ответы Re: PATCH: CITEXT 2.0 v3  ("David E. Wheeler" <david@kineticode.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Fwd: Proposal - UUID data type
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: PATCH: CITEXT 2.0 v3