From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Built-in CTYPE provider |
Date: | 2023-12-19 20:59:03 |
Message-ID: | CA+TgmoY_xNx6JKu-ewW8YmO3Qd7WidVxwx829Q=MZ3FVF0NnpA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 18, 2023 at 2:46 PM Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-12-19 23:00:19 | Re: Add a perl function in Cluster.pm to generate WAL |
Previous Message | Tristan Partin | 2023-12-19 20:43:49 | Add support for __attribute__((returns_nonnull)) |