JS
Yaroslav Schekin
Ну не показывайте / не отвечайте на конкретные вопросы — это не наша проблема, в конце концов. ;)
Походу нельзя просто взять и проапдейтить какуюто из часте CompositeKey, помогло удаление и вставка
Size: a a a
2020 June 16
YS
Походу нельзя просто взять и проапдейтить какуюто из часте CompositeKey, помогло удаление и вставка
Это т.н. чушь.
А known issue здесь — это то, что Вы не читаете, что Вам пишут, IMNSHO.
И да, выделение некоторого количества случайных слов в ответ на чьи-то вопросы ответом не является, just FYI.
А known issue здесь — это то, что Вы не читаете, что Вам пишут, IMNSHO.
И да, выделение некоторого количества случайных слов в ответ на чьи-то вопросы ответом не является, just FYI.
s
Кракозябр Кракозябрович
Приветсвую.
Столкнулся с интересной проблемой. Требуется регистронезависимый поиск вхождения подстроки в таблице. Пробовал
SELECT post, id FROM users WHERE post ILIKE '%начальник%';
SELECT post, id FROM users WHERE post ~* 'начальник';
SELECT post, id FROM users WHERE LOWER(post) ~* LOWER('начальник');
В общем различные комбинации ~*
Все варианты не работают пока не напишешь "Начальник", я блин что-то не так делаю или у нас меркурий не в том юпитере и база просто тупит?
Столкнулся с интересной проблемой. Требуется регистронезависимый поиск вхождения подстроки в таблице. Пробовал
SELECT post, id FROM users WHERE post ILIKE '%начальник%';
SELECT post, id FROM users WHERE post ~* 'начальник';
SELECT post, id FROM users WHERE LOWER(post) ~* LOWER('начальник');
В общем различные комбинации ~*
Все варианты не работают пока не напишешь "Начальник", я блин что-то не так делаю или у нас меркурий не в том юпитере и база просто тупит?
SHOW LC_CTYPE;
SHOW LC_COLLATE;
SHOW LC_COLLATE;
YS
Кракозябр Кракозябрович
Приветсвую.
Столкнулся с интересной проблемой. Требуется регистронезависимый поиск вхождения подстроки в таблице. Пробовал
SELECT post, id FROM users WHERE post ILIKE '%начальник%';
SELECT post, id FROM users WHERE post ~* 'начальник';
SELECT post, id FROM users WHERE LOWER(post) ~* LOWER('начальник');
В общем различные комбинации ~*
Все варианты не работают пока не напишешь "Начальник", я блин что-то не так делаю или у нас меркурий не в том юпитере и база просто тупит?
Столкнулся с интересной проблемой. Требуется регистронезависимый поиск вхождения подстроки в таблице. Пробовал
SELECT post, id FROM users WHERE post ILIKE '%начальник%';
SELECT post, id FROM users WHERE post ~* 'начальник';
SELECT post, id FROM users WHERE LOWER(post) ~* LOWER('начальник');
В общем различные комбинации ~*
Все варианты не работают пока не напишешь "Начальник", я блин что-то не так делаю или у нас меркурий не в том юпитере и база просто тупит?
А у меня работает всё это. С таким, например:
Похоже на проблемы с collation.
WITH users(post, id) AS (
VALUES ('Начальник', 1),
('Не начальник', 2),
('Кто-то ещё', 3)
)
SELECT ...
Похоже на проблемы с collation.
КК
s
Кракозябр Кракозябрович
Оно?
Ну так юникодом и не пахнет
YS
Кракозябр Кракозябрович
Оно?
Оно, конечно:
WITH users(post, id) AS (
VALUES ('Начальник' COLLATE "C", 1),
('Не начальник', 2),
('Кто-то ещё', 3)
)
SELECT post, id FROM users WHERE post ~* 'начальник';
s
Был бы юникод задан, было бы так:
junkydb=# SHOW LC_COLLATE;
lc_collate
-------------
en_US.UTF-8
(1 row)
junkydb=# SHOW LC_CTYPE;
lc_ctype
-------------
en_US.UTF-8
(1 row)
junkydb=# select lower('НачалЬникА');
lower
------------
начальника
(1 row)
КК
Был бы юникод задан, было бы так:
junkydb=# SHOW LC_COLLATE;
lc_collate
-------------
en_US.UTF-8
(1 row)
junkydb=# SHOW LC_CTYPE;
lc_ctype
-------------
en_US.UTF-8
(1 row)
junkydb=# select lower('НачалЬникА');
lower
------------
начальника
(1 row)
тоесть теперь гуглить как менять/починять кодировку?
КК
Yaroslav Schekin
Оно, конечно:
WITH users(post, id) AS (
VALUES ('Начальник' COLLATE "C", 1),
('Не начальник', 2),
('Кто-то ещё', 3)
)
SELECT post, id FROM users WHERE post ~* 'начальник';
сложнааа покачто)
s
Кракозябр Кракозябрович
тоесть теперь гуглить как менять/починять кодировку?
Могу и так сказать - создать базу с нужной кодировкой и перекинуть туда данные
s
Потому что на ходу оно не меняется
КК
какое счастье что не прод база
YS
Кракозябр Кракозябрович
какое счастье что не прод база
Тогда легче пересоздать.
Хотя, такой подход (когда collation базы "C", а только для тех полей, где нужны другие, они задаются явно) — это тоже вариант, в принципе.
Хотя, такой подход (когда collation базы "C", а только для тех полей, где нужны другие, они задаются явно) — это тоже вариант, в принципе.
s
Yaroslav Schekin
Тогда легче пересоздать.
Хотя, такой подход (когда collation базы "C", а только для тех полей, где нужны другие, они задаются явно) — это тоже вариант, в принципе.
Хотя, такой подход (когда collation базы "C", а только для тех полей, где нужны другие, они задаются явно) — это тоже вариант, в принципе.
Если данные там уже лежат, то почти наверняка человек, не знавший про collation, их умудрится поломать. Собственно, насколько я в теме, не просто так оно на ходу не меняется.
YS
Если данные там уже лежат, то почти наверняка человек, не знавший про collation, их умудрится поломать. Собственно, насколько я в теме, не просто так оно на ходу не меняется.
> то почти наверняка человек, не знавший про collation, их умудрится поломать.
Это да. Подход "default C + индивидуальные" нужно применять осознанно, конечно.
> Собственно, насколько я в теме, не просто так оно на ходу не меняется.
Потому что всё (индексы, например), что упорядочено без явной collation, идёт по порядку default — как тут поменяешь, на практике (разве что перезаписать это всё)? Поэтому и возможности нет, наверное (работы по реализации было бы много — практического толка где-то 0).
Это да. Подход "default C + индивидуальные" нужно применять осознанно, конечно.
> Собственно, насколько я в теме, не просто так оно на ходу не меняется.
Потому что всё (индексы, например), что упорядочено без явной collation, идёт по порядку default — как тут поменяешь, на практике (разве что перезаписать это всё)? Поэтому и возможности нет, наверное (работы по реализации было бы много — практического толка где-то 0).
s
> Потому что всё (индексы, например), что упорядочено без явной collation, идёт по порядку default — как тут поменяешь,
Ну да, я к тому и веду, что много чего тут же в тыкву превратится)КК
Был бы юникод задан, было бы так:
junkydb=# SHOW LC_COLLATE;
lc_collate
-------------
en_US.UTF-8
(1 row)
junkydb=# SHOW LC_CTYPE;
lc_ctype
-------------
en_US.UTF-8
(1 row)
junkydb=# select lower('НачалЬникА');
lower
------------
начальника
(1 row)
я ж забыл сказать, бд сейчас временно на маке развёрнута. Я так понимаю раньше точно была проблема с кириллицей там🤨
Б
есть чат по MSSQL?
Б
спасибо