Postgres case insensitive username

Существует возможность использовать citext. Однако его производительность значительно хуже, особенно учитывая что хотелось бы использовать URI /users/username.

Триггер.
И вообще вероятность того, что 2 пользователя одновременно отошлют форму с одинаковым юзернеймом но в разных регистрах, какая?
ИМХО надуманная проблема.

когда может создаться два пользователя 'username' и 'Username' при одновременном сабмите формы регистрации не смотря на то что в приложении была произведена проверка

не смотря на то что была произведена проверка

Проверка чего? Уточни, ты хочешь сделать чтобы пользователь с именем UserName не мог зарегистрироваться, если в базе есть пользователь userName?

Ну а вообще postgres вот такое позволяет -
UNIQUE (lower(username))

При этом хотелось бы сохранить оригинальный ввод

Храни в базе два поля:

1) username (где имена reduced to lowercase);

2) displayname (где имена в original input).

Второе поле показывать, по первому проверять уникальность при регистрации.

Храни в базе два поля

Зачем?

Зачем?

При этом хотелось бы сохранить оригинальный ввод

Подумай что делает этот констрейнт - UNIQUE (lower(username))

А что он делает?

1) Создает индекс с именами приведенными в нижний регистр, чтобы потом сравнивать при вставке?

2) При каждой операции вставки приводит имеющиеся имена в нижний регистр чтобы сравнить с новым?

Так, просто интересно как там внутри у постгреса?

как там внутри у постгреса?

Как внутри реализовано точно не знаю, думаю хранит индекс по lower() и при запросах ищет по нему.

И вообще вероятность того, что 2 пользователя одновременно отошлют форму с одинаковым юзернеймом но в разных регистрах, какая? ИМХО надуманная проблема.

Вот с такими мыслями и пишут сбойный софт. Вы в m$ случайно не подрабатываете?

Как проблема может быть надуманной если в продакшене она может привести к огромным проблемам?

Ну а вообще postgres вот такое позволяет - UNIQUE (lower(username))

Хорошая идея.

Как проблема может быть надуманной если в продакшене она может привести к огромным проблемам?

Это к каким? Ну будет у тебя с некоторой очень малой вероятностью 2 пользователя с похожими именами, и что дальше?

Вы в m$ случайно не подрабатываете?

Честно говоря, я вобще нигде не подрабатываю, и программирую в основном just for fun.

Это к каким? Ну будет у тебя с некоторой очень малой вероятностью 2 пользователя с похожими именами, и что дальше?

Это по вашему ничего страшного? А ничего что один юзер сможет залогиниться как другой юзер. И страшно подумать ещё какая путаница сможет произойти. Один юзер сможет пользоваться ресурсами другого юзера, если система работает с финансовыми средствами сможет завладеть средствами другого юзера. Так и до судебных разбирательств недолго. Ваше халатное отношение просто возмутительно!!!

А ничего что один юзер сможет залогиниться как другой юзер.

Каким образом, у вас там авторизация только по логину без пароля?

Ваше халатное отношение просто возмутительно!!!

Упал со стула!!! Я твой работник что-ли?

Да ты конфет объелся, да еще и с такой экспрессией :3

Один юзер сможет пользоваться ресурсами другого юзера

Два разных юзернейма это два разных пользователя, права и ресурсы у них разные. Для отсталых, могу даже привести вполне очевидный пример:

$ touch username
$ touch Username
$ chmod 777 username
$ chmod 444 Username

если система работает с финансовыми средствами сможет завладеть средствами другого юзера

Только если обманом невнимательных мудаков из техподдержки, которые не видят разницы между именами, отличающимися в один символ. К несчастью, таких очень даже не мало.

Каким образом, у вас там авторизация только по логину без пароля?

Совершенно ни к месту, в этом плане pi11, tyler19 и tyIer19 все равны, зная логин совершенно без разница насколько отличаются юзернеймы в написании.

зная логин совершенно без разница насколько отличаются юзернеймы в написании.

То есть в случае, если пароль не спрашивается. Ты наверное хотел спросить что-то вроде:

у вас там авторизация не учитывает регистр юзернейма?

Что вполне возможно, если писали мудаки. Я бы понял еще, если регистрация не позволяла зарегиться с отличием в регистре, но case insensitive авторизация это вздор.

Я хотел спросить, то что спросил.

Хотя окей, не вздор. если приучить обезьянок к беспорядку (во время регистрации), то и при логине лучше позволить беспорядок.

Зачем? Твой вопрос не имеет смысла.

Не думаю что авторизация без пароля (ну или другой системы аутентификации) имеет смысл.
Поэтому регистр символов имени пользователя врядли будет чем-то секретным, а следовательно не должен использоваться как единственное средство для аутентификации. Конечно все может быть, поэтому и спросил.

Зачем case insensitive username? Ты говоришь, что «хочется сохранить оригинальный ввод», но при этом задаешь вопрос про регистронезависимость. Лично мне кажется, что тут какое-то огромное противоречие.

Никакого противоречия здесь нет. Хочется что бы если пользователь зарегистрировался как 'MyName' он бы так и отображался в веб приложении а не как 'myname' (т.е. что бы Camel Case выделял отдельные слова в его имени). В то же время что бы другой пользователь не смог зарегистрироваться как 'myname' что вызовет путаницу у паскалистов и других непрограммистов.

И вообще вероятность того, что 2 пользователя одновременно отошлют форму с одинаковым юзернеймом но в разных регистрах, какая?

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

Такой вариант помоему тут вообще не рассматривается.