From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeremy Schneider <schneider@ardentperf.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Built-in CTYPE provider
Date: Tue, 19 Dec 2023 16:18:01 -0800
Message-ID: <6682ce676994b18eaa904591cb6618abebe2d3e8.camel@j-davis.com> (raw)
In-Reply-To: <CA+TgmoY_xNx6JKu-ewW8YmO3Qd7WidVxwx829Q=MZ3FVF0NnpA@mail.gmail.com>
References: <ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel@j-davis.com>
<6f3958d8-46a7-4fd1-88de-4d58e84abe0c@ardentperf.com>
<b3e445d3958c4d71bd3027f2ba6423c36b90353d.camel@j-davis.com>
<578cf85a-1c27-434c-b89e-27a64d8e023a@ardentperf.com>
<d4616159b36de9451edd35fa7b2f36f299005c9c.camel@j-davis.com>
<CA+TgmoY_xNx6JKu-ewW8YmO3Qd7WidVxwx829Q=MZ3FVF0NnpA@mail.gmail.com>
On Tue, 2023-12-19 at 15:59 -0500, Robert Haas wrote:
> 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.
For the database default collation, I suspect a lot of users would jump
at the chance to have "vanilla" semantics. Tailoring is more important
for individual collation objects than for the database-level collation.
There are reasons you might select a tailored database collation, like
if the set of users accessing it are mostly from a single locale, or if
the application connected to the database is expecting it in a certain
form.
But there are a lot of users for whom neither of those things are true,
and it makes zero sense to order all of the text indexes in the
database according to any one particular locale. I think these users
would prioritize stability and performance for the database collation,
and then use COLLATE clauses with ICU collations where necessary.
The question for me is how good the "vanilla" semantics need to be to
be useful as a database-level collation. Most of the performance and
stability problems come from collation, so it makes sense to me to
provide a fast and stable memcmp collation paired with richer ctype
semantics (as proposed here). Users who want something more probably
want the Unicode "root" collation, which can be provided by ICU today.
I am also still concerned that we have the wrong defaults. Almost
nobody thinks libc is a great provider, but that's the default, and
there were problems trying to change that default to ICU in 16. If we
had a builtin provider, that might be a better basis for a default
(safe, fast, always available, and documentable). Then, at least if
someone picks a different locale at initdb time, they would be doing so
intentionally, rather than implicitly accepting index corruption risks
based on an environment variable.
Regards,
Jeff Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pgsql@j-davis.com, robertmhaas@gmail.com, schneider@ardentperf.com
Subject: Re: Built-in CTYPE provider
In-Reply-To: <6682ce676994b18eaa904591cb6618abebe2d3e8.camel@j-davis.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox