Unicode, сортировки, а я маленький такой
Dec. 4th, 2017 08:07 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
beldmitКоллега сегодня обнаружил, что при сортировке в уникодной локали PostgreSQL выдаёт записи в таком порядке:
_a
a
_c
d
что несколько контринтуитивно.
Вскрытие показало, что алгоритм сравнения в Unicode довольно хитровывернутый в этом месте. При сортировке в локали базы в итоге символы подчёркивания игнорируются.
Вылечилось это привешиванием COLLATE "C" на искомую колонку, который даёт сравнение, грубо говоря, побайтовое. Но вообще поведение документированное, но неочевидное.
_a
a
_c
d
что несколько контринтуитивно.
Вскрытие показало, что алгоритм сравнения в Unicode довольно хитровывернутый в этом месте. При сортировке в локали базы в итоге символы подчёркивания игнорируются.
Вылечилось это привешиванием COLLATE "C" на искомую колонку, который даёт сравнение, грубо говоря, побайтовое. Но вообще поведение документированное, но неочевидное.
no subject
Date: 2017-12-04 07:11 pm (UTC)Есть еще что-то вроде
"а а"
"а (б)"
"а в"
(пишу по памяти, может быть не правильно запомнил конкретику)
И в некоторых случаях непонятны две вещи:
а) как сделать так чтобы сортировалось как надо
б) как сделать так чтобы везде сортировалось одинаково
no subject
Date: 2017-12-04 10:09 pm (UTC)https://www.arbinada.com/ru/taxonomy/term/58
no subject
Date: 2017-12-05 09:44 am (UTC)Претензии тут надо бы предъявлять к авторам локали...
А что касается самого постгреса... Любой софт стоит перед выбором: тащить все с собой, или полагаться на решения операционной системы. И тут не угадаешь.
С одной стороны локаль большинства линуксов не знает например, что "20 апреля" положено писать с маленькой буквы. Что вынуждает либо тащить свою локаль, либо делать какие-то хаки.
С другой стороны как автор софта ты не знаешь всех нюансов, знать, например, что принято в японии по всем поводам просто невозможно. Поэтому хочется это таки оставить на откуп авторам локали везде где можно...
Решение тащить все с собой -- тоже не правильное... Например ситуация когда библиотека тащит с собой свою информацию о таймзонах, приводит к тому, что половина системы уже знает что Москве время уже не переводится, а другая половина -- еще нет... Этот расклад может принести много радости.
Короче нету какого-то правильного пути...
no subject
Date: 2017-12-05 10:17 am (UTC)no subject
Date: 2017-12-06 02:28 pm (UTC)Хотя в целом для сказанного мной принципиальной разницы нет, в любом случае по отношению к постгресу и локаль и уникод -- это внешние явление по отношению к самой БД.
no subject
Date: 2017-12-07 07:29 pm (UTC)no subject
Date: 2017-12-08 10:50 am (UTC)Про первый: pgAdmin имеет отношение к постгресу как Norton Commander к досу. Даже еще меньшее...
Про, "Если б я имел слона".
Есть ли в постгресе бинарный тип фиксированной длины?
Если бы мне приспичило хранить хэш именно в поле фиксированной динны, я бы создал бы под это отдельный тип. См select * from pg_type where typlen >8;
Человек который знает зачем ему нужно именно так, без особого труда осилит это сделать. Остальным пойдет и varlen.
Error: operator does not exist: money > integer
Вот на эту историю у меня рука конечно тянется посмотреть, а че тут не так, и не надо ли поправить. Однако сразу представляю, сколько радости может принести price + 0.00001, в смысле историй с округление денег. Поэтому может быть и сравнивать с числами не надо...
Остальные истории, у меня не вызвали особого беспокойства. То есть да, наверное некрасивенько. Но вот логически объяснить, что должно быть именно по другому, тем более объяснить сообществу, тем более с условием того что у кого-то что-то после этого может сломаться -- я не возьмусь...
В третьей записи я жалоб при беглом просмотре не нашел...
no subject
Date: 2017-12-08 10:46 pm (UTC)no subject
Date: 2017-12-09 06:06 am (UTC)Ну, тут простите, контр-аргумент детсадовский "А если несколько СУБД пойдут с крыши прыгать, постгрес тоже должен пойти?"
Сообщество принципиально не ориентируется на нюансы реализации других СУБД, а ориентируется на SQL стандарт и практическую целесообразность...
Поэтому ответ на вопрос "зачем нужно" имеет большое практическое значение.
no subject
Date: 2017-12-09 10:35 am (UTC)no subject
Date: 2017-12-09 07:58 pm (UTC)Могу предложить предложение: у меня рано или поздно откроется таймслот на постгресовый патч, могу посвятить его вам (только пожалуйста что-нибудь не сложное). Но для этого нужно будет объяснить почему оно нужно, сначала мне, а потом сообществу... Вот это вот с моей точки зрения будет конкретика...
no subject
Date: 2017-12-10 04:52 pm (UTC)Позвольте и мне поглумиться немного, заранее приношу извинения, ибо обидеть не хочу.
На нашей ERP тесты производительности такие:
Firebird - 1
PostgreSQL - 1/4
SQL Server - 1/10
Есди будет время на таймслот, устраните более чем двукратное отставание от SQL Server. Один из наших клиентов будет рад :)
no subject
Date: 2017-12-14 09:33 pm (UTC)Ну... вам ехать, или поныть? Если поныть, то заход удачный. Для остальных задач -- не очень...
Позвольте и мне поглумиться немного, заранее приношу извинения, ибо обидеть не хочу.
Я тогда в том же ключе отвечу, ок?
На нашей ERP тесты производительности такие:
Firebird - 1
PostgreSQL - 1/4
SQL Server - 1/10
Есди будет время на таймслот, устраните более чем двукратное отставание от SQL Server. Один из наших клиентов будет рад :)
А кнопку "сделать зашибись" вам не сделать?
Какие запросы больше всего тормозят систему? Прикладывал ли спец по постгресу руку к оптимизации схемы данных и оптимизации настройки?
Оптимизация скорости роботы запроса несколько выше моих нынешних умений (вот money < 15 это я точно осилю), я могу с профайлером поразвлекаться. Но простите, не с такой постановкой задачи не разу...