Re: PATCH: CITEXT 2.0 v2

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PATCH: CITEXT 2.0 v2
Date: 2008-07-07 18:54:53
Message-ID: 4872667D.4030502@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-07-07 18:57:38 Re: PATCH: CITEXT 2.0 v2
Previous Message Alvaro Herrera 2008-07-07 18:54:02 Re: PATCH: CITEXT 2.0