Re: Add CASEFOLD() function. - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Add CASEFOLD() function.
Date
Msg-id ab9a2b8d25ff826cb785a1d0f21391538ce2aff6.camel@j-davis.com
Whole thread Raw
Responses Re: Add CASEFOLD() function.
List pgsql-hackers
On Thu, 2025-06-19 at 16:36 +0100, Thom Brown wrote:
> Ease of use, perhaps. It seems easier to use:
>
> column_name cftext
>
> rather than:
>
> CREATE COLLATION case_insensitive_collation (
>     PROVIDER = icu,
>     LOCALE = 'und-u-ks-level2',
>     DETERMINISTIC = FALSE
> );

We could auto-create such a collation at initdb time for ICU-enabled
builds.

> But I see the arguments against it. It creates an unnecessary
> dependency on an extension, and if someone wants to ignore both case
> and accents, they may resort to using 2 extensions (citext +
> unaccent)
> when none are needed.

There are at least three ways to do case insensitivity (or other kinds
of equivalence):

* Explicit function calls in queries, as well as index and constraint
definitions. E.g. expression index on LOWER(), queries that explicitly
do "LOWER(x) = ..."

* Wrap those function calls up in a separate data type, like citext.

* Non-deterministic collations.

Given that we have collations, which are a way of organizing alternate
behaviors for existing data types, I'm not sure I see the need for
creating an entirely separate data type.

> I guess I don't feel strongly about it either
> way.

Are you a user of citext? I'm genuinely interested in the use cases,
and whether the separate-data-type approach has merits that are missing
in the other approaches.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: Add CASEFOLD() function.
Next
From: Robert Treat
Date:
Subject: Re: Add CASEFOLD() function.