Re: PATCH: CITEXT 2.0 v4

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