Каковы рекомендуемые параметры сортировки для уникального столбца электронной почты PostgreSQL?

если сопоставить, то какой именно?

Какой бы вариант вы ни предпочли, речь идет не обязательно о выборе определенного параметра сортировки из встроенного списка, а о его настройке таким образом. Как показано в документе:
демо на 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

Если вы спрашиваете, какой языковой стандарт рекомендуется для сортировки без учета регистра, я бы сказал, что это общий язык, описанный выше, но в конечном итоге это не имеет значения. Другие в основном различаются тем, как они сортируют вещи, и, если они специально не настроены для этой цели, я не думаю, что они не согласятся с равенством, которого вы хотите unique.

Я предположил, что вы спрашиваете, какая конкретная сортировка является рекомендацией, и в этом случае такой вещи нет - стандартная установка не поставляется со встроенной регистронезависимой сортировкой из коробки. Японский, арабский и китайский являются примерами языков, «нечувствительных к регистру» (символы не имеют верхних и нижних вариантов), но основанные на них параметры сортировки сами по себе не учитывают регистр, когда имеют дело с другими алфавитами.

Если вы спрашиваете о производительности, то в этом тесте на 150 тыс. 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, если оно работает для любой кодировки.

Если вы хотите спросить о проверке и нормализации адреса электронной почты с помощью ограничения столбца, это немного другой вопрос.