PostgreSQL 15中的ICU功能

PostgreSQL 15的新特性之一是您可以在数据库和实例级别上使用ICU排序。

在PostgreSQL 10中，我们首先在PostgreSQL中添加了ICU支持。这允许您定义使用ICU作为后台语言环境库(在PostgreSQL中称为排序提供程序或语言环境提供程序)的排序对象，作为现有“libc”提供程序的替代方案。例如,

CREATE COLLATION german (provider = icu, locale = 'de');

例如，这允许使用ICU提供的各种排序定制功能

CREATE COLLATION upperfirst (provider = icu, locale = 'en@colCaseFirst=upper');

随着ICU支持的引入，我们还添加了排序规则的版本跟踪，以便PostgreSQL可以检测操作系统中的排序规则定义何时发生变化，与PostgreSQL开始使用时相比。(在某些平台上，这种支持已经扩展到libc排序提供程序。)

遗憾的是，所有这一切只允许您对声明使用ICU支持的排序规则的特定列有选择地使用ICU。默认情况下，不可能自动为整个数据库使用ICU。

这在PostgreSQL 15中是可行的。

例如，使用ICU语言环境初始化一个新实例:

initdb -D pgdata --locale-provider=icu --icu-locale=de

当然，你也可以使用高级的ICU功能，比如

initdb -D pgdata --locale-provider=icu --icu-locale='en@colCaseFirst=upper'

还有一些遗留的问题:要从服务器操作中完全删除libc区域设置并不容易。

首先，PostgreSQL中仍然有一些代码使用libc语言环境设施。我所知道的唯一在实践中有明显影响的代码是文本搜索代码的“isalpha”等测试。最终，如果这样配置，我们应该将所有这些转换为使用ICU库调用。

其次，扩展中也可能存在类似的问题，而且很难找到。

第三，libc语言环境设置以不完全明显的方式相互作用。例如，如果您使用gettext来本地化程序消息，则可以使用LC_MESSAGES区域设置进行配置，该设置可以随时更改。但是附加到数据库的LC_CTYPE设置决定了gettext使用的编码。你需要将它设置为与数据库编码匹配的东西，否则gettext输出会被错误编码。

因此，在任何情况下，您仍然需要设置libc语言环境。调用看起来像这样

initdb -D pgdata --locale-provider=icu --icu-locale=de --locale=de_DE.utf8

我意识到这是相当令人困惑的，但至少复杂性包含在initdb调用(以及可选的createdb调用)中。(当然，和之前一样，——locale选项默认是locale环境设置。)

(实用提示:对于文本搜索和gettext问题，实际的lc_ctype区域设置没有区别，只要它不是“C”并匹配数据库编码。因此，例如，可以将lc_ctype硬编码为类似en_US的内容。Utf8的部署脚本。这并不影响text search认为文本是什么语言，或者gettext的输出语言是什么(因此您仍然可以根据需要定制这些语言)，它只是确保它们正确处理字符编码和分类。)

以下是我未来的计划:

Ⅰ、修复不遵守ICU设置的其余libc场所的使用。我们得看看这案子到底有多深。例如，文本搜索问题可能是编程的一个小问题，但gettext问题似乎更难修复。

Ⅱ、在数据库和实例级别上还不支持不确定排序规则。不确定排序规则是一种特性(PostgreSQL 12中的新特性)，它允许您定义，例如，不区分大小写或忽略重音的排序规则。但并不是所有的函数和操作符都支持这种排序规则，因此将其用于默认排序规则将破坏一些查询，包括在系统视图中使用的一些查询，因此我们现在禁用了它。

Ⅲ、(从技术上讲，非确定性排序特征与ICU特征是正交的。但是由于libc语言环境提供程序不支持不确定排序，因此它通常被认为是ICU功能的一部分。)

Ⅳ、我们可以通过PostgreSQL公开更多ICU排序定制选项。如果用户想把“B”放在“A”之前，或者其他不那么愚蠢的东西，这将给他们完全的灵活性。

Ⅴ、我想把ICU设为默认。我不知道我们是否会切换initdb选项的默认值。但我想先说到ICU和UTF-8，所有二进制文件都是在启用ICU的情况下构建的，软件包或docker镜像默认使用ICU排序进行初始化。为了达到这个目的，我们需要反馈当前设置中是否有任何尚未完全准备好的东西。

PG考试咨询