Re: PATCH: CITEXT 2.0 v4 - Mailing list pgsql-hackers
From | Robert Treat |
---|---|
Subject | Re: PATCH: CITEXT 2.0 v4 |
Date | |
Msg-id | 200807161420.14824.xzilla@users.sourceforge.net Whole thread Raw |
In response to | Re: PATCH: CITEXT 2.0 v4 ("David E. Wheeler" <david@kineticode.com>) |
Responses |
Re: PATCH: CITEXT 2.0 v4
|
List | pgsql-hackers |
On Wednesday 16 July 2008 13:54:25 David E. Wheeler wrote: > 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? > AIUI, your propsing the following: select 'x'::citext = 'X'::citext;?column? ----------t (1 row) select 'x'::citext ~ 'X'::citext;?column? ----------f (1 row) I understand the desire for flexibility, but the above seems wierd to me. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
pgsql-hackers by date: