​Сегодня в эфире наброс на regexp’ы аж о двух постах.

Присоединюсь по всем пунктам, разве что за исключением того, что проверять регеспы можно статическими методами (раз, два). Если вы, конечно, не собираете их динамически :) А если собираете,... я даже не знаю как это можно назвать...

У меня как-то была история о регекспах, когда я парсил базу билетного агенства.


В holistic.dev тоже не обошлось без этой черной юниксово-перловой магии :)

Нет, запросы не парсятся регекспами, это невозможно. Для этого используется оригинальный AST-парсер из postgresql.
Выковыривать его оттуда отдельное приключение. Т.к. разработчики не поставляют его как отдельный продукт, они не переживают за обратную совместимость. Поэтому у дерева постоянно появляются и пропадают узлы :)

Регекспы используются для подготовки сорцов, перед скармливанием их в AST-парсер. Т.к. мы маленький стартап и не можем позволить себе написать грамматику, например, под JetBrains Grammar-Kit, приходится выкручиваться.

Т.к. изначально инструмент планировалось интегрировать с IDE, то хотелось сделать так, чтобы при наличии синтаксической ошибке в одной из sql-команд, только эта команда игнорировалась, а остальное парсилось. Именно так все работает в IDE от Jetbrains. Хотелось сделать так же, но нативный парсер такого не умеет - он падает на первой же синтаксической ошибке.

Идея делать плагин для IDE была отложена, а функционал остался. Если в playground сделать несколько ddl-команд, часть из которых будет с синтаксическими ошибками, это не помешает проверке. (выделение ошибочных мест в DDL будет позже, сейчас можно заметить, что поля из таблицы b не попали в экспорт типов).
Часто спрашивают - почему не подсвечивается отсутствующая таблица в запросе? Сейчас мы не ориентируемся на разработчиков, а у DBA не бывает невалидных запросов :) Но справедливости ради, это правило находится в процессе разработки и нашлись corner cases, которые требуют доработки парсера :)

К слову, если у вас есть экспертиза в AST-парсерах, я был бы рад пообщаться (@antonrevyako)