Message-ID: <db496682c6656ac64433f05f8821e561bbf4d105.camel@j-davis.com>
Subject: Re: Built-in CTYPE provider
From: Jeff Davis <pgsql@j-davis.com>
To: Noah Misch <noah@leadboat.com>, Peter Eisentraut <peter@eisentraut.org>
Cc: Daniel Verite <daniel@manitou-mail.org>, Robert Haas
 <robertmhaas@gmail.com>,  Jeremy Schneider <schneider@ardentperf.com>,
 pgsql-hackers@postgresql.org
Date: Wed, 03 Jul 2024 14:19:07 -0700
In-Reply-To: <20240702230333.8d.nmisch@google.com>
References: <4135cf11-206d-40ed-96c0-9363c1232379@eisentraut.org>
	 <7451f81ba0cb512222ab759de8ca1cffe44e9acb.camel@j-davis.com>
	 <1f309153-8198-4efa-86dd-8c304ec0040c@eisentraut.org>
	 <a21b515000f121244db2a5570d4292d19df23379.camel@j-davis.com>
	 <20240629220857.fb.nmisch@google.com>
	 <1ecfeb4d2b1b7f119fa917d3052a3aecfaf4f425.camel@j-davis.com>
	 <20240701230352.2c.nmisch@google.com>
	 <da7a19008c2b1f19b3f91b446fe09847512694f1.camel@j-davis.com>
	 <20240702165145.af.nmisch@google.com>
	 <1200e97b-3a52-43c6-8b16-20cf45f58249@eisentraut.org>
	 <20240702230333.8d.nmisch@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/db496682c6656ac64433f05f8821e561bbf4d105.camel%40j-davis.com>
Precedence: bulk

On Tue, 2024-07-02 at 16:03 -0700, Noah Misch wrote:
> Each packager can choose their dependencies so the v16 providers
> don't have
> the problem.=C2=A0 With the $SUBJECT provider, a packager won't have that
> option.

While nothing needs to be changed for 17, I agree that we may need to
be careful in future releases not to break things.

Broadly speaking, you are right that we may need to freeze Unicode
updates or be more precise about versioning. But there's a lot of
nuance to the problem, so I don't think we should pre-emptively promise
either of those things right now.

Consider:

* Unless I made a mistake, the last three releases of Unicode (14.0,
15.0, and 15.1) all have the exact same behavior for UPPER() and
LOWER() -- even for unassigned code points. It would be silly to
promise to stay with 15.1 and then realize that moving to 16.0 doesn't
create any actual problem.

* Unicode also offers "case folding", which has even stronger stability
guarantees, and I plan to propose that soon. When implemented, it would
be preferred over LOWER()/UPPER() in index expressions for most use
cases.

* While someone can pin libc+ICU to particular versions, it's
impossible when using the official packages, and additionally requires
using something like [1], which just became available last year. I
don't think it's reasonable to put it forth as a matter-of-fact
solution.

* Let's keep some perspective: we've lived for a long time with ALL
text indexes at serious risk of breakage. In contrast, the concerns you
are raising now are about certain kinds of expression indexes over data
containing certain unassigned code points. I am not dismissing that
concern, but the builtin provider moves us in the right direction and
let's not lose sight of that.


Given that no code changes for v17 are proposed, I suggest that we
refrain from making any declarations until the next version of Unicode
is released. If the pattern holds, that will be around September, which
still leaves time to make reasonable decisions for v18.

Regards,
	Jeff Davis

[1] https://github.com/awslabs/compat-collation-for-glibc