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
|
Список | 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 по дате отправления: