Re: Add CASEFOLD() function.

From: Thom Brown <thom(at)linux(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Joe Conway <mail(at)joeconway(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add CASEFOLD() function.
Date: 2025-06-19 15:36:29
Message-ID: CAA-aLv57dEeoX__Osx4k2yda6G2V-i=MYxr0HrH6U+yyYw5wKQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 19 Jun 2025 at 15:51, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 19.06.25 06:03, Thom Brown wrote:
> > Late to the party, but is there an argument for porting this to the
> > citext type? Or supplementing the extension with an additional type
> > ("cftext"? *shrug*). It currently uses lower(), so our current
> > recommendation for dealing with all unicode characters is to use
> > nondeterministic collations.
>
> What is the motivation for wanting a citext variant instead of using
> nondeterministic collations?

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
);

column_name text COLLATE case_insensitive_collation

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. I guess I don't feel strongly about it either
way.

Thom

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2025-06-19 15:43:36 Re: Correct docs about partitions and EXCLUDE constraints
Previous Message Tom Lane 2025-06-19 15:29:55 Re: BackendKeyData is mandatory?