INSERT REGEXP - удвоение точек

SELECT word FROM words WHERE word REGEXP '^КАРП.В\$'

такой запрос по идее должен находить запись КАРПОВ в таблице (она там есть), но не находит, а вот такой запрос его находит:

SELECT word FROM words WHERE word REGEXP '^КАРП..В\$'

пробовал так:
SELECT word FROM words WHERE word REGEXP '^КАРП[А-Я]В\$' - не находит
SELECT word FROM words WHERE word REGEXP '^КАРП[А-Я][А-Я]В\$ - находит

в чем дело не могу понять? Почему надо удваивать точки или символьный класс? А просто символы нормально ищутся?

P.S.
просто SELECT word FROM words WHERE word REGEXP '^КАРПОВ\$' тоже находит

P.S.S. Это может быть связано с кодировкой многобайтной utf-8?

(Отредактировано автором: 13 Октября, 2013 - 21:19:57)

С чего это вдруг?
Не помню ни одного диалекта регулярных выражений, в котором одиночный символ успешно совпадал с двумя символами.

-----
PostgreSQL DBA

Еще раз проверил, но кажется все правильно, одиночный символ должен совпадать с одним символом - буквой О:

SELECT word FROM words WHERE word REGEXP '^КАРП.В\$'
такой запрос по идее должен находить запись КАРПОВ

Или я что-то не понимаю?

Кажется это я туплю. Завтра на свежую голову перечитаю.

-----
PostgreSQL DBA

Немного поэкспериментировал еще:
"SELECT word FROM words WHERE word REGEXP '^КАРПОВ$'"; - находит в базе слово КАРПОВ, логично

"SELECT word FROM words WHERE word REGEXP '^КАРП[О]В$'"; - вот такой запрос запись не находит, хотя кажется что в принципе все аналогично

"SELECT word FROM words WHERE word REGEXP '^КАРП[О][О]В$'"; - а вот такая запись слово КАРПОВ в базе находит.

P.S. с LIKE 'КАРП_В' все прокатывает, один символ подчеркивания - одна буква. Но мне надо именно REGEXP разобраться, запрос на самом деле сложнее нужен.

P.S.S. вот что еще вычитал в http://dev[dot]mysql[dot]com/doc/refman/[dot][dot][dot]#operator_regexp


Warning

The REGEXP and RLIKE operators work in byte-wise fashion, so they are not multi-byte safe and may produce unexpected results with multi-byte character sets. In addition, these operators compare characters by their byte values and accented characters may not compare as equal even if a given collation treats them as equal.


P.S.S.S.
сохранил файл в win1251, поля таблицы тоже, запрос:
SELECT word FROM win1251 WHERE word REGEXP '^КАРПОВ$'
выдал ошибку:
Illegal mix of collations (cp1251_general_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'regexp'

(Отредактировано автором: 14 Октября, 2013 - 09:14:23)

Хм, печально. Я думал, у mysql дела с utf хорошо обстоят.

Гугление даёт 2 варианта:
0) никак. Проблеме уже седьмой год пошёл: http://bugs[dot]mysql[dot]com/bug.php?id=30241
1) ставить UDF: https://github[dot]com/mysqludf/lib_[dot][dot][dot]ludf_preg#readme

Потенциально некорректно, результат нужно перепроверять на приложении, но можно отбрасывать заведомо неверные варианты:

-----
PostgreSQL DBA

Что же так все печально в программировании??? Все через какую-то задницу делается
Потенциально некорректно делать не хочется, потому что если это у меня на Денвере заработает, не факт что на хостинге потом это будет нормально.

А задача была такая:
Есть такое понятие буквенно-цифровой код (БЦК). Применяется для запоминания чисел. Каждому числу сопоставляется пара согласных, 0 -н,м 1 -г,ж 2 -д,т и т.п. Чтобы запомнить число подбирается слово в котором эти согласные идут в нужном порядке, например ГНОМ будет соответствовать числу 100. Слова запоминаются гораздо легче цифр Зная слово легко получить соответствующее число. А вот придумать подходящее слово сходу не получается.
Хотелось написать запрос, который будет в базе по числу искать подходящие слова, что-то типа такого
^[ГЖ][А][АЕИЙОУЪЫЬЭЮЯ]*[НМ][АЕИЙОУЪЫЬЭЮЯ]*[НМ].* (для числа 100)

Собственно говоря каждому слову какое-то одно число соответствует, правильнее наверно будет в базу еще одно поле добавить с этим числом, прочитать слова потихоньку, по одному перевести в числа.

Буквы известны заранее?
Тогда можно использовать альтернативы:
^(Г|Ж)А(А|Е|И|Й|О|У|Ъ|Ы|Ь|Э|Ю|Я)*
Всё равно, очевидно, регулярка будет строиться динамически, есть явно повторяющиеся фрагменты.


Речь о том, что можно использовать сперва грубый фильтр на стороне базы, затем на приложении проверить и отсеять результаты, выбранные ошибочно. Регулярки в PHP используют библиотеку PCRE, там юникод учитывается (но по соображениям обратной совместимости нужно указывать модификатор u).

-----
PostgreSQL DBA