Skip site navigation (1) Skip section navigation (2)

PATCH: CITEXT 2.0 v4

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: PATCH: CITEXT 2.0 v4
Date: 2008-07-16 05:23:21
Message-ID: 34AAF859-C4A5-4E6A-A20C-E836631EE32F@kineticode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Howdy,

I've attached a new patch with the latest revisions of for the citext  
contrib module patch. The changes include:

* Using strlen() to pass string lengths to the comparison function,
   since lowercasing the value can change the length. Per Tom Lane.
* Made citextcmp consistently return int32, per Tom Lane.
* Made the hash index function return the proper value, per Tom Lane.
* Removed the COMMENTs and GRANTs from citext.sql.in.
* Added a cast function from bpchar to citext, as suggested by Tom Lane.
* Set the storage type for CITEXT to "extended", to ensure that it will
   be toastable. Per Tom Lane.
* Fixed the COMMUTATOR of <=.
* Changed the cast from citext to bpchar from implicit to assignment.
   This eliminates ambiguous function resolutions.
* Eliminated superflous functions, per Tom Lane.
* Removed unnecessary `OPERATOR()` calls in NEGATORs and the like.
* Added binary in/out functions. Per Tom Lane
* Added an explicit shell type to make the output a bit quieter.
* Converted tests to pure SQL and omitted multibyte tests (though a
   few remain commented-out).
* Reorganized and expanded the documentation a bit.

This version is far better than I started with, and I'm very grateful  
for the feedback.

Now, I have a few remaining questions to ask, mostly just to get your  
opinions:

* 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?

* 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

Attachment: citext4.patch.gz
Description: application/x-gzip (10.2 KB)

Responses

pgsql-hackers by date

Next:From: cinuDate: 2008-07-16 06:10:50
Subject: postmaster.pid not visible
Previous:From: David FetterDate: 2008-07-16 05:22:57
Subject: Re: [PATCHES] WITH RECURSIVE updated to CVS TIP

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group