есть и с 16

пошёл искать lenovo x280 и выяснилось, что его уже выпустили, только он не ноутбук

пришлось идти гуглить (:

Ребят у меня чет реплика приболела: LOG: expected password response, got message type 88 сыплет в лог, подключение по md5 + hostip =(

Всем привет, такой вопрос. Пострес умеет строить индексы на поле, значения которого эквивалентны регулярным выражениям?

Т.е. я бы делал что-то типа WHERE regex ~ 'foo-bar' а оно мне строки где в поле regex есть ^foo или bar$

Везде случаи, когда в WHERE подается регулярное выражение, а у меня по сути наоборот, база регулярок, и надо найти все записи с регулярками под строку в условии. Может я невозможного хочу и поэтому ничего нагуглить не смог?

были попытки такое сделать на основе n-gram индекса, но, имхо, это реально под очень простые регулярки.

вот если Александр Коротков - это Александр из простгреспро, он может точнее сказать ;)

Его презентацию за 2012й год я уже посмотрел, ага

всем привет. Ребят подскажите как правильнее сделать. Хочу чтоб при создании таблицы сразу навешивались гранты для нее. Делаю так: ALTER DEFAULT PRIVILEGES IN SCHEMA data GRANT SELECT ON TABLES TO data_read; если таблицу создает юзер с ролью овнера этой схемы, то права не навешиваются. Если суперюзер то все ок. Рассматриваю также вариант триггера в стиле: CREATE EVENT TRIGGER on_create_table ON ddl_command_end WHEN TAG IN ('CREATE TABLE') EXECUTE PROCEDURE on_create_table_func(); как правильнее сделать? PG 9.5

Всем привет, такой вопрос. Пострес умеет строить индексы на поле, значения которого эквивалентны регулярным выражениям?

Привет! Это возможно на базе RUM. Я уже не помню, делал я это или нет...

Сейчас посмотрю и скажу точнее.

Сейчас посмотрю и скажу точнее.

Было бы здорово!

Да, я это делал, но оооочень давно... https://www.postgresql.org/message-id/CAPpHfduMvS=sGPNh_88bUo3TEg_KhxV7s81Fa+ZV96yadgff2g@mail.gmail.com

Это были ещё те времена, когда я пытался пропихнуть хранение доп. информации в GIN.

Сейчас это стал RUM.

По-идее нужно это вытаскивать и запихивать в отдельный contrib.

Вернее в отдельный extension: pg_trgm_rum

RUM и просто для триграм может дать прирост скорости.

+1 задачка для стажёра будет ?

Дмитрий, BTW, вы не могли бы поделиться каким-нибудь набором данных для исследований индексного поиска по регуляркам? (как прямого, так и обратного)

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

Может на ваших данных мой подход себя хорошо покажет.

У меня не такой уж и огромный (пока) набор данных

Юз-кейс легаси редирект регулярки, для роутера в приложении

Когда приложение генерит 404 мы перехватываем исключение и ищем в базе урл среди всех регулярок

Для одного из приложений у меня пока только 6000 регулярок, но и на них запрос работает 200мс

В целом пойдет, но опаска есть

Когда приложение генерит 404 мы перехватываем исключение и ищем в базе урл среди всех регулярок

но зачем? давать нечеткое соответсвие урлов?

но зачем? давать нечеткое соответсвие урлов?

Не понял вопроса если честно

Регулярки могут быть динамическими, т.к. нет конечного списка вариантов.

нафига 404 урл искать по регуляркам?

С захватом группы

огласите всю задачу пожалуйста

^/path/(\d+)$ => /path2/$1

В колонке regex хранится ^/path/(\d+)$ а в колонке target хранится переадресация

Когда движек сайта не может найти страницу, то как fallback срабатывает legacy router который идет в базу

И идет "глобальные" переадресации

может это говно на нгинх повесить? все 6000 правил?

Нет, мы как раз оттуда вытащить хотим

не надо

Т.к. тогда все лоика будет в одном месте

(:

Надо

У нас штат из СЕО обезьянок

Они каждый день делают редиректы

Конфиг nginx нет и не будет никаких сил поддерживать

а морда на чем?

+ сайт поддерживает свою логику дляредиректов (корректных) которые связаны с бизнес объектами

Там недолжно быть конфликтов между легаси редиректами и новыми, поэтому все в БД должно лежать

Чтобы нормально валидаторы работали. Или придется все списки дублировать по два раза

просто одно дело 1 раз скомпиленый регексп

а другое - ты будешь каждый раз их компилить при сверках

это тормоза

Это только если возникает 404

морда на чем? похапе?

Да

Таких запросов не будет много

Т.к. по сути это fallback

ну то есть если я завалю тебя скриптом делающим 404 с 3 адресов например - я тебе уложу сайт

1-5% если не меньше

Не уложишь

это как фокус в свое время с друпаловской таксономией

причем уложу малыми усилиями

В PHP есть куда более медленные места.

Предлагаю не обсуждать здесь PHP :)

ну да. одно из них preg_match

ну а где ты матчить будешь?

(:

в БД?

По сути вопроса есть что? :)

это говно один хрен лучше выносить наружу из пыха.

Да, я это делал, но оооочень давно... https://www.postgresql.org/message-id/CAPpHfduMvS=sGPNh_88bUo3TEg_KhxV7s81Fa+ZV96yadgff2g@mail.gmail.com

А варианта с голым SQL я так понимаю нету?

У нас RDS :(

как вариант ловить в пыхе 404 и отваливать его через X-internal-Redirect на другой сервис который будет матчингом заниматься

а список урлов+скомпиленых рег в этом сервисе обновлять по ключику(типа текущая версия списка) в мемкеше или редисе. например

если у тебя именно регулярки

Илья, сколько еще раз надо повторить, что проблема не в скорости PHP и функции preg_match?

ну как. сколько прегматчей ты бушь делать на 1 вызов 404?

Мне индекс по базе как раз и нужен, чтобы база данных мне вернула одну (!) запись с корректным target

ОДИН

?

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

Расскажите это Александру Короткову

индекс по вычисляемой функции значение которой зависит от вводимой строки? лол

Наверное, все люди, у кого фамилии начинаются на "Корот*" — наркоманы. Кто ж его знает

ну так это логично же что он тогда должен скомпилить все регулярки чтобы быстро матчится )

короче яб навалял служебный сервис на ноде или на го.... один хрен это говно в памяти гонять

Да да, над больше микросервисов.

Я бы хотел меньше оффтопика и более конкретных предложений в стиле Александа Короткова )

ну я патч посмотрел. он там походу компилит регулярки. и скомпиленое хранит

(:

Задача сформулирована бизнесом, так, что решение ее при прочих равных именно такое. Как минимум врятли у нас будет даже 10000 регулярок на приложение. В условиях нашей архитектуры, когда каждое приложение это отдельная база данных, по сути слайс с центральной, в которой хранятся все данные по всем приложениям, то в каждой из баз будет максимум по 10000 регулярок, что даст не более чем 400-500мс по скорости. В угоду бизнеса и того, что фокус направлен на юзабилити решения для конечных редакторов и специалистов по SEO, я готов даже оставить самый простой вариант с SELECT *, REGEXP_MATCHES('blue-tomato-gutschein', regex) FROM fallback_redirects; запросом, плюс, специальный rate-limiter для Ильи Азарова :)

Цена времени разработчиков больше, чем железа и процессорнго времени в амазоне. То, как эффективно работает отдел редакторов и как корректно они создают контент и следят за редиректами и прочим хламом — вот та метрика, которая важна для бизнеса. А не сколько там preg_match работает на реквест который возникает в 5% случаев.

5% может быть очень дофига.

а может быть ошибка редактора с сылкой в статье или картинкой )

и это будет не 5% )

короче не мой проект. мне пофиг.