него входили поля, которые могут содержать null, но при этом null считался равным null'у.
То есть при наличии в таблице строк и unique ограничения на (user_id, surname, count):
user_id | surname | count
500 | null | 10
null | Иванов | 15
Добавить строки (null, Иванов, 15) и (500, null, 10) было нельзя.
Нашел в документации, что за это отвечает параметр TRANSFORM-NULL-EQUALS в postgresql.conf. Включил его в конфигурации, перезагрузил БД.
Действительно, теперь select null = null возвращает true. При этом, unique constraint всё еще не работает.
По умолчанию unique создается с помощью стандартного индекса btree. Подозреваю, что дело в этом (в документации написано, что при использовании сложных операндов сравнения может возникать ситуация, что null != null даже с включенным параметром).
Подскажите, пожалуйста, что делать в данной ситуации. Может быть, стоит поменять индекс на другой, или же использовать другой параметр в конфигурации?
Если вас не смущает тот факт, что вы собираетесь использовать null значения, то посмотрите в сторону, напр., COALESCE(user_id, -1) вместо простого user_id.
Функциональный индекс создайте с coalesce условно(
К сожалению, таблица создавалась не мной, больше 2ух лет назад, а сейчас используется на проде. Надо менять, но пока руки не дошли. Действительно, идея с Coalesce в голову не пришла. Спасибо, попробую!
Также рекомендую откатить параметр transform_null_equals в его значение по умолчанию. Иначе рискуете получить "неожиданные" результаты работы некоторых запросов.
Спасибо, так и сделаю. Но вообще интересна конкретная причина такого поведения индекса при включенном transform_null_equals
А вы посмотрите на ошибку, которая получается при создании уникального индекса.
Обсуждают сегодня