Re: Update Unicode data to Unicode 16.0.0

On Fri, 2025-03-21 at 17:15 +0100, Peter Eisentraut wrote:
> And we knew at the time the builtin collation
> provider was added that it would have certain problems with the
> Unicode
> table updates, and we accepted it with the understanding that this
> would
> not change our procedures.

Correct. That was called out by me in the initial proposal for the
builtin collation provider and documented explicitly.

> Those who are now trying to make the builtin collation provider have
> properties that it does not have and was not intended to have when it
> was added, they would need to arrange the work to make it have those
> properties if they want them, rather than insist that progress in
> other
> areas must stop because they are content with the current state.

It does feel like the goalposts are moving. That's not necessarily bad
by itself -- our expectations should go up. But the way it's happening
in this thread makes it feel like new obligations are being put on the
people already working on collation improvements, in particular Peter
and I.

Robert indicated that there might be some willing hackers, and perhaps
even appetite for larger-scope projects in this area, which is great
news. A lot of what's happening in this area is non-controversial, and
more attention would be an unqualified win. For instance, Peter put
some work into better support for non-deterministic collations, and I
had some ideas there:

https://www.postgresql.org/message-id/024c9b9aa834f668496ef95700b57e50bf3f4808.camel%40j-davis.com

but I didn't have time to work on that this cycle. (Maybe my idea would
be hard to implement or not work at all, or maybe Peter and Tom already
have better ideas, but that's different from being controversial.)

For the many people who think multi-lib is the way to go, the shortest
path involves someone taking a look at this prerequisite:

https://www.postgresql.org/message-id/cb580fec46ea4ca96dd4bbde9d2769360e097d01.camel%40j-davis.com

Some technical review would be nice, but really what I needed was
someone to say "this small regression in a worst case due to an
unavoidable indirect function call is not worth worrying about". It
might be a bit late now, though, as a big refactoring right before FF
seems like a bad idea. So it will probably slip until July, adding risk
that any other multi-lib work (which I am not promising to do) might
slip to PG20, which users will see at the end of 2027. Ugh.

Regards,
Jeff Davis