Re: Built-in CTYPE provider - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Built-in CTYPE provider
Date
Msg-id CA+TgmoY_xNx6JKu-ewW8YmO3Qd7WidVxwx829Q=MZ3FVF0NnpA@mail.gmail.com
Whole thread Raw
In response to Re: Built-in CTYPE provider  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Built-in CTYPE provider
List pgsql-hackers
On Mon, Dec 18, 2023 at 2:46 PM Jeff Davis <pgsql@j-davis.com> wrote:
> The whole concept of "providers" is that they aren't consistent with
> each other. ICU, libc, and the builtin provider will all be based on
> different versions of Unicode. That's by design.
>
> The built-in provider will be a bit better in the sense that it's
> consistent with the normalization functions, and the other providers
> aren't.

FWIW, the idea that we're going to develop a built-in provider seems
to be solid, for the reasons Jeff mentions: it can be stable, and
under our control. But it seems like we might need built-in providers
for everything rather than just CTYPE to get those advantages, and I
fear we'll get sucked into needing a lot of tailoring rather than just
being able to get by with one "vanilla" implementation.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "Tristan Partin"
Date:
Subject: Add support for __attribute__((returns_nonnull))
Next
From: Michael Paquier
Date:
Subject: Re: Add a perl function in Cluster.pm to generate WAL