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
