PostgreSQL 唯一电子邮件列的推荐排序规则是什么？

Question

大多数地方 建议使用 lower(email)

 索引或数据类型 

citext

 建立唯一的电子邮件索引。

但是

citext手册建议对所有情况使用排序规则，而不是现在citext

：

考虑使用非确定性排序规则代替此模块。

那么，目前，在 PostgreSQL 中处理唯一电子邮件列的推荐方法是什么？

索引

lower()

？ 

citext

还在吗？或者如果整理的话，到底是哪一个？

Answer 1

如果核对的话，到底是哪一篇？

无论您喜欢哪一种 - 不一定要从内置列表中选择一种特定的排序规则，而是以这种方式配置一个排序规则。如

文档中所示：
db<>fiddle 的演示

CREATE COLLATION case_insensitive (
  provider = icu, 
  locale = 'und-u-ks-level2', --undefined(root,generic), but you can pick a language
  deterministic = false);
SELECT 'a' = 'A' COLLATE case_insensitive; -- true

如果您询问哪种

locale 被推荐用于不区分大小写的排序规则，我会说这是上面的通用的，但最终并不重要。其他人主要在如何排序方面有所不同，除非专门为此目的进行配置，否则我认为他们不会不同意您想要的平等unique

。

我假设您问哪个特定的

排序规则是建议，在这种情况下，没有这样的东西 - 标准安装不附带开箱即用的内置不区分大小写的排序规则。日语、阿拉伯语和中文是“不区分大小写”语言的示例（字符没有大写/小写变体），但基于它们的排序规则在处理其他字母时本身并不不区分大小写。

如果您询问

性能，在这个测试中，对150k 90％唯一的随机样本以及我在10M上运行的另一个测试，表达式索引在lower()

列上使用

text

和

collate "C"

往往表现最好，紧随其后的是使用不区分大小写的 icu 排序规则的文本列上的常规索引。 

citext

 远远落后。

---

我的观点是电子邮件的字符集无法解释。 email rfc使用ascii，删除了几个字符，它不关心国际化标准。

有不止一个

“电子邮件 RFC”，因此您可能会争辩说，即使是 “电子邮件 RFC” 的含义也可以解释。而且，它不是“仅限ASCII，删除了几个字符”，或者至少已经有一段时间了。这是一个相对较旧的线程讨论这些主题，链接到维基百科上的一个很好的例子：

下面的示例地址不会由基于 RRFC 5322 的服务器处理，但受到 RFC 6530 的允许。符合此要求的服务器将能够处理这些：

带有变音符号的拉丁字母：Pelé@example.com
希腊字母：δοκιμή@παράδειγμα.δοκιμή
繁体字：我买@屋企.香港
日文字符：二ノ宫@黒川.日本
西里尔字母：медведь@с-балалайкой.рф
梵文字符：संपर्क@डाटामेल.भारत

我觉得我需要划清界限：字符集是关于

编码。您询问的排序规则用于“排序和相等”，并且大多数排序规则适用于所有编码选项。你可以通过检查pg_collation.collencoding = -1来判断：

collencoding int4

排序规则适用的编码，如果适用于任何编码，则为 -1

如果您想通过列约束询问电子邮件地址验证和标准化，这是一个

略有不同的问题

。