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

From Zdenek Kotala
Subject Re: PATCH: CITEXT 2.0 v2
Date
Msg-id 4872667D.4030502@sun.com
Whole thread Raw
In response to Re: PATCH: CITEXT 2.0 v2  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: PATCH: CITEXT 2.0 v2  ("David E. Wheeler" <david@kineticode.com>)
Re: PATCH: CITEXT 2.0 v2  ("Pavel Stehule" <pavel.stehule@gmail.com>)
List pgsql-hackers
David E. Wheeler napsal(a):
> On Jul 7, 2008, at 07:41, Zdenek Kotala wrote:
> 
>> However, It seems to me that code is ok now (exclude citex_eq). I 
>> think there two open problems/questions:
>>
>> 1) regression test -
>>
>>  a) I think that regresion is not correct. It depends on en_US locale, 
>> but it uses characters which is not in related character repertoire. 
>> It means comparing is not defined and I guess it could generate 
>> different result on different OS - depends on locale implementation.
> 
> That I don't know about. The test requires en_US.UTF-8, at least at this 
> point. How are tests run on the build farm? And how else could I ensure 
> that comparisons are case-insensitive for non-ASCII characters other 
> than requiring a Unicode locale? Or is it just an issue for the sort 
> order tests? For those, I could potentially remove accented characters, 
> just as long as I'm verifying in other tests that comparisons are 
> case-insensitive (without worrying about collation).

Hmm, it is complex area and I'm not sure if anybody on planet know correct 
answer :-). I think that best approach is to keep it as is and when a problem 
occur then it will be fixed.

>>  b) pgTap is something new. Need make a decision if this framework is 
>> acceptable or not.
> 
> Well, from the point of view of `make installcheck`, it's invisible. 
> I've submitted a talk proposal for pgDay.US on ptTAP. I'm happy to 
> discuss it further here though, if folks are interested.

Yeah, it is invisible, but question is why don't put it as a framework to common 
place. But it is for another discussion.

>> 2) contrib vs. pgFoundry
>>
>> There is unresolved answer if we want to have this in contrib or not. 
>> Good to mention that citext type will be obsoleted with full collation 
>> implementation in a future. I personally prefer to keep it on 
>> pgFoundry because it is temporally workaround (by my opinion), but I 
>> can live with contrib module as well.
> 
> I second what Andrew has said in reply to this issue. I'll also say 
> that, since people *so* often end up using `WHERE LOWER(col) = 
> LOWER(?)`, that it'd be very valuable to have citext in contrib, 
> especially since so few folks seem to even know about pgFoundry, let 
> alone be able to find it. I mean, look at these search results:

I understand it but there is parallel project which should solve this problem 
completely I guess in "close" future (2-3years). Afterward this module will be 
obsolete and it will takes times to remove it from contrib. It seems to me that 
have citext in contrib only for two releases is not optimal solution.
    Zdenek



-- 
Zdenek Kotala              Sun Microsystems
Prague, Czech Republic     http://sun.com/postgresql



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: PATCH: CITEXT 2.0
Next
From: Adriano Lange
Date:
Subject: GEQO Publications