module provides a case-insensitive
character string type,
. Essentially, it internally calls
when comparing values. Otherwise, it behaves almost
Consider using nondeterministic collations (see Section 22.214.171.124 ) instead of this module. They can be used for case-insensitive comparisons, accent-insensitive comparisons, and other combinations, and they handle more Unicode special cases correctly.
This module is considered
, that is, it can be
installed by non-superusers who have
on the current database.
The standard approach to doing case-insensitive matches
has been to use the
function when comparing values, for example
SELECT * FROM tab WHERE lower(col) = LOWER(?);
This works reasonably well, but has a number of drawbacks:
It makes your SQL statements verbose, and you always have to remember to use
loweron both the column and the query value.
It won't use an index, unless you create a functional index using
If you declare a column as
PRIMARY KEY, the implicitly generated index is case-sensitive. So it's useless for case-insensitive searches, and it won't enforce uniqueness case-insensitively.
data type allows you to eliminate calls
in SQL queries, and allows a primary key to
is locale-aware, just
, which means that the matching of upper case and
lower case characters is dependent on the rules of
setting. Again, this behavior is
identical to the use of
in queries. But because it's
done transparently by the data type, you don't have to remember to do
anything special in your queries.
F.8.2. How to Use It
Here's a simple example of usage:
CREATE TABLE users ( nick CITEXT PRIMARY KEY, pass TEXT NOT NULL ); INSERT INTO users VALUES ( 'larry', sha256(random()::text::bytea) ); INSERT INTO users VALUES ( 'Tom', sha256(random()::text::bytea) ); INSERT INTO users VALUES ( 'Damian', sha256(random()::text::bytea) ); INSERT INTO users VALUES ( 'NEAL', sha256(random()::text::bytea) ); INSERT INTO users VALUES ( 'Bjørn', sha256(random()::text::bytea) ); SELECT * FROM users WHERE nick = 'Larry';
statement will return one tuple, even though
column was set to
and the query
F.8.3. String Comparison Behavior
performs comparisons by converting each string to lower
case (as though
were called) and then comparing the
results normally. Thus, for example, two strings are considered equal
would produce identical results for them.
In order to emulate a case-insensitive collation as closely as possible,
-specific versions of a number of string-processing
operators and functions. So, for example, the regular expression
exhibit the same behavior when
: they both match case-insensitively.
The same is true
, as well as for the
. If you'd like to match
case-sensitively, you can cast the operator's arguments to
Similarly, all of the following functions perform matching
case-insensitively if their arguments are
For the regexp functions, if you want to match case-sensitively, you can
flag to force a case-sensitive match. Otherwise,
you must cast to
before using one of these functions if
you want case-sensitive behavior.
citext's case-folding behavior depends on the
LC_CTYPEsetting of your database. How it compares values is therefore determined when the database is created. It is not truly case-insensitive in the terms defined by the Unicode standard. Effectively, what this means is that, as long as you're happy with your collation, you should be happy with
citext's comparisons. But if you have data in different languages stored in your database, users of one language may find their query results are not as expected if the collation is for another language.
As of PostgreSQL 9.1, you can attach a
citextcolumns or data values. Currently,
citextoperators will honor a non-default
COLLATEspecification while comparing case-folded strings, but the initial folding to lower case is always done according to the database's
LC_CTYPEsetting (that is, as though
COLLATE "default"were given). This may be changed in a future release so that both steps follow the input
citextis not as efficient as
textbecause the operator functions and the B-tree comparison functions must make copies of the data and convert it to lower case for comparisons. Also, only
textcan support B-Tree deduplication. However,
citextis slightly more efficient than using
lowerto get case-insensitive matching.
citextdoesn't help much if you need data to compare case-sensitively in some contexts and case-insensitively in other contexts. The standard answer is to use the
texttype and manually use the
lowerfunction when you need to compare case-insensitively; this works all right if case-insensitive comparison is needed only infrequently. If you need case-insensitive behavior most of the time and case-sensitive infrequently, consider storing the data as
citextand explicitly casting the column to
textwhen you want case-sensitive comparison. In either situation, you will need two indexes if you want both types of searches to be fast.
The schema containing the
citextoperators must be in the current
public); if it is not, the normal case-sensitive
textoperators will be invoked instead.
The approach of lower-casing strings for comparison does not handle some Unicode special cases correctly, for example when one upper-case letter has two lower-case letter equivalents. Unicode distinguishes between case mapping and case folding for this reason. Use nondeterministic collations instead of
citextto handle that correctly.
David E. Wheeler
Inspired by the original
module by Donald Fraser.