Conversation

I blogged about how we're going to be watching out for libc changes that can potentially corrupt indexes on Linux, FreeBSD and Windows in PostgreSQL 14 (patches for other operating systems welcome!)

Quote Tweet

Azure Database for PostgreSQL

@AzureDBPostgres

Dec 12, 2020

Hot off the press. Collations are a gnarly detail of the world of language. And they can & do change. See how #PostgreSQL 14 will make things better with collation version tracking - in this lovely post from @MengTangmu techcommunity.microsoft.com/t5/azure-datab

Replying to

Life would be easier if all databases use C collation for internal storage. They are used by multiple users from multiple countries with multiple languages anyway.

Replying to

and

But even when users are uniformly geographically dispersed we can do better. A generic UCA collator will cover many important cases. There is relatively little controversy about how to sort Katakana, say. And when the behavior looks wrong, it is still *less* wrong (than C case).

Replying to

and

In the same spirit, "compromise" collations exist. This includes EOR (without tailoring), which was designed for use in inter-European contexts: en.wikipedia.org/wiki/European_. In general localization is continuous, not discrete.

en.wikipedia.org

European ordering rules - Wikipedia

10:55 PM · Dec 13, 2020Twitter Web App

Replying to

and

On the icu-support ML, there's a recent thread (bit.ly/3gJZljn "Options for Immutable Collation?") that I found quite interesting about how Unicode is unlikely to support any immutable collation beyond "C".

Replying to

and

UCA stuff is written with localization in mind. Indexing stuff is considered without assuming too much about DB requirements. This makes sense to me. It really isn't their job to have a strong opinion on what DB systems ought to do.