postgresql 中使用 utf8 的多种语言

Multiple languages with utf8 in postgresql

究竟 是如何无缝支持存储在 postgres 的 utf8 字符集中的所有语言的?我们似乎需要指定一个特定于语言的排序规则以及字符集,例如 en_US.utf8。如果我没记错的话,我们无法在同一个 utf8 列中同时存储英文 (en_US) 和中文 (zh_CN),同时保持 any 种有意义的整理行为。如果我将一列定义为en_US.utf8,它应该如何处理包含中文(zh_CN)字符/字节序列的值?实际情况是单个列值可以包含多种语言(例如:"Hello and 晚安"),并且根本无法根据一种语言进行整理。

是的,我可以物理存储任何字符序列;但是在包含英文、德文、中文、日文和韩文字符串的 en_US.utf8 列上进行排序的定义行为是什么?

我知道 mysql 的 utf8mb4_unicode_ci 整理并不完美,并且它没有遵循任何关于如何整理整个 unicode 集的既定标准。我已经可以听到反对 mysql 的人群叹息 mysql 的语言不可知排序规则是任意的、语义上毫无意义的,甚至是完全无效的。但事实是,它工作得很好,并且满足了 utf8 = 多语言 unicode 支持的期望。

是不是 postgres 非常固执地认为 语义上 不正确来整理整个 unicode 范围?我知道开发人员在 "doing things according to spec" 方面非常严格,但这种无法兼顾多种语言的能力至少可以说是令人沮丧的。我是否遗漏了解决多语言问题的东西,或者官方的立场是单个 utf8 列可以处理任何语言,但一次只能处理一种语言?

你是对的,永远不会有一种完美的跨语言整理字符串的方法。

PostgreSQL 决定不创建自己的排序规则,而是使用操作系统提供的排序规则。这背后的想法是避免重新发明轮子并减少维护工作。
因此,传统的 PostgreSQL 对你的问题的回答是:如果你想要一个对不同语言的字符串都能很好地工作的字符串排序规则,向你的操作系统供应商投诉或选择一个提供这种排序规则的操作系统。

但是,这种方法存在 PostgreSQL 社区意识到的缺点:

  • 很少有人(如果有的话)根据操作系统提供的整理支持来决定操作系统。

  • PostgreSQL 的排序行为取决于底层操作系统,这导致在邮件列表上经常出现困惑用户的问题。

  • 对于某些操作系统,排序规则行为可能会在操作系统升级期间发生变化,从而导致数据库索引损坏(参见示例 this thread)。

很可能是 PostgreSQL 改变了它的方法;已经多次尝试使用 ICU libraries instead of operating system collations (see for example this recent thread),这将缓解其中的一些问题。