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

From David E. Wheeler
Subject Re: PATCH: CITEXT 2.0 v4
Date
Msg-id 15397E1D-2897-4863-A48D-7B1FB9753354@kineticode.com
Whole thread Raw
In response to PATCH: CITEXT 2.0 v4  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: PATCH: CITEXT 2.0 v4  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
On Jul 15, 2008, at 22:23, David E. Wheeler wrote:

> * The README for citext 1.0 on pgFoundry says:
>
>> I had to make a decision on casting between types for regular  
>> expressions and
>> decided that if any parameter is of citext type then case  
>> insensitive applies.
>> For example applying regular expressions with a varchar and a  
>> citext will
>> produce a case-insensitive result.
>>
>> Having thought about this afterwards I realised that since we have  
>> the option
>> to use case-insensitive results with regular expressions I should  
>> have left the
>> behaviour exactly as text and then you have the best of both  
>> worlds... oh well
>> not hard to change for any of you perfectionists!
>
> I followed the original and made all the regex and LIKE comparisons  
> case-insensitive. But maybe I should not have? Especially since the  
> regular expression functions (e.g., regexp_replace()) and a few non- 
> regex functions (e.g., replace()) still don't behave case- 
> insensitively?

I was thinking about this a bit last night and wanted to fill things  
out a bit.

As a programmer, I find Donald Fraser's hindsight to be more  
appealing, because at least that way I have the option to do matching  
against CITEXT strings case-sensitively when I want to.

OTOH, if what we want is to have CITEXT work more like a case- 
insensitive collation, then the expectation from the matching  
operators and functions might be different. Does anyone have any idea  
whether regex and LIKE matching against a string in a case-insensitive  
collation would match case-insensitively or not? If so, then maybe the  
regex and LIKE ops and funcs *should* match case-insensitively? If  
not, or if only for some collations, then I would think not.

Either way, I know of no way, currently, to allow functions like  
replace(), split_part(), strpos(), and translate() to match case- 
insensitiely, even if we wanted to. Anyone have any ideas?

> * If the answer is "no", how can I make those functions behave case- 
> insensitively? (See the "TODO" tests.)
>
> * Should there be any other casts? To and from name, perhaps?

Thanks,

David



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: ExecuteTruncate quirk: expects a unique list of relations
Next
From: Robert Treat
Date:
Subject: Re: PATCH: CITEXT 2.0 v4