Unicode, сортировки, а я маленький такой

[beldmit]

Коллега сегодня обнаружил, что при сортировке в уникодной локали PostgreSQL выдаёт записи в таком порядке:

_a
a
_c
d

что несколько контринтуитивно.

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

Вылечилось это привешиванием COLLATE "C" на искомую колонку, который даёт сравнение, грубо говоря, побайтовое. Но вообще поведение документированное, но неочевидное.

Comments

[nataraj]

А... в первый раз не осилил визуально распарсить дизайн, и не понял что у статей есть "read more"

Про первый: pgAdmin имеет отношение к постгресу как Norton Commander к досу. Даже еще меньшее...

Про, "Если б я имел слона".

Есть ли в постгресе бинарный тип фиксированной длины?
Если бы мне приспичило хранить хэш именно в поле фиксированной динны, я бы создал бы под это отдельный тип. См select * from pg_type where typlen >8;

Человек который знает зачем ему нужно именно так, без особого труда осилит это сделать. Остальным пойдет и varlen.

Error: operator does not exist: money > integer
Вот на эту историю у меня рука конечно тянется посмотреть, а че тут не так, и не надо ли поправить. Однако сразу представляю, сколько радости может принести price + 0.00001, в смысле историй с округление денег. Поэтому может быть и сравнивать с числами не надо...

Остальные истории, у меня не вызвали особого беспокойства. То есть да, наверное некрасивенько. Но вот логически объяснить, что должно быть именно по другому, тем более объяснить сообществу, тем более с условием того что у кого-то что-то после этого может сломаться -- я не возьмусь...

В третьей записи я жалоб при беглом просмотре не нашел...

[cross_join]

Контрвопросы "зачем это нужно?" не засчитываются. Ситуация описана в заголовке: поддержка нескольких СУБД. Если б не пара клиентов, давно бы уже похоронил эту ветку, как нерентабельную.

[nataraj]

поддержка нескольких СУБД
Ну, тут простите, контр-аргумент детсадовский "А если несколько СУБД пойдут с крыши прыгать, постгрес тоже должен пойти?"
Сообщество принципиально не ориентируется на нюансы реализации других СУБД, а ориентируется на SQL стандарт и практическую целесообразность...
Поэтому ответ на вопрос "зачем нужно" имеет большое практическое значение.

[cross_join]

Если бы контрибуторы Постгреса действительно ориентировались на стандарт SQL, то подобных вопросов бы просто не возникло. Почему миры стандартов и промышленных СУБД пересекаются, а не совпадают - в книжке по той же ссылке.

[nataraj]

У меня такое ощущение, что вы просто жалуетесь...

Могу предложить предложение: у меня рано или поздно откроется таймслот на постгресовый патч, могу посвятить его вам (только пожалуйста что-нибудь не сложное). Но для этого нужно будет объяснить почему оно нужно, сначала мне, а потом сообществу... Вот это вот с моей точки зрения будет конкретика...

[cross_join]

Это опенсурсная песня стара: "код открыт - исправь сам" или "заплати - исправим" или "станцуй, а мы, может быть исправим, если понравится" :)
Позвольте и мне поглумиться немного, заранее приношу извинения, ибо обидеть не хочу.
На нашей ERP тесты производительности такие:
Firebird - 1
PostgreSQL - 1/4
SQL Server - 1/10
Есди будет время на таймслот, устраните более чем двукратное отставание от SQL Server. Один из наших клиентов будет рад :)

[nataraj]

Это опенсурсная песня стара: "код открыт - исправь сам" или "заплати - исправим" или "станцуй, а мы, может быть исправим, если понравится" :)
Ну... вам ехать, или поныть? Если поныть, то заход удачный. Для остальных задач -- не очень...

Позвольте и мне поглумиться немного, заранее приношу извинения, ибо обидеть не хочу.
Я тогда в том же ключе отвечу, ок?

На нашей ERP тесты производительности такие:
Firebird - 1
PostgreSQL - 1/4
SQL Server - 1/10
Есди будет время на таймслот, устраните более чем двукратное отставание от SQL Server. Один из наших клиентов будет рад :)
А кнопку "сделать зашибись" вам не сделать?

Какие запросы больше всего тормозят систему? Прикладывал ли спец по постгресу руку к оптимизации схемы данных и оптимизации настройки?

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