Review sql grammar to fix required whitespaces

Запрос create index some_idx on warehouse using HASH(id) не отрабатывает, потому что сейчас в грамматике после типа индекса ожидается явный пробел. Нужно заменить на опциональный пробел.

Может быть, где-то по грамматике ещё затаились подобные ошибки.

В Pest все пробелы по умолчанию опциональны. Правильно было бы переработать грамматику, и убрать чрезмерное использование атомарных правил и форсированных пробелов. Заодно я ожидаю, что от этого парсер станет существенно быстрее.

У нас были проблемы с тем что запросы а ля createtablekek работали, нам такого не надо. От этого появилась необходимость использовать явные пробелы

Ты говоришь про другое. Ты говоришь про правильную токенизацию ключевых слов (после них должны быть пробелы или спецсимволы). Это можно реализовать по-другому, с помощью предикатов на предыдущие и следующие символы. Но я вообще не про это, а про WO, которые отслеживают опциональные пробелы - это поведение по умолчанию, прописывать это явно бессмысленно. Это усложняет чтение и поддержку грамматики, и также существенно замедляет парсер.

В идеале, конечно, хорошо бы избавиться от pest и использовать парсер со стандартным пайплайном, на основе лексера. Лексер проблемы с createtablekek решает тривиально, на порядок быстрее, чем текущее решение, и при этом не усложняет грамматику.

Я немного повозился с грамматикой, и беру назад слова насчёт исправления пробелов. Т.е. концептуально утверждение верно, но я не вижу способа как-то постепенно модифицировать грамматику, чтобы исправить это. Pest не предоставляет средств для удобного инкрементального рефакторинга: нет возможности inline (без объявления новых правил) модифицировать свойства парсинга (чтение без опциональных пробелов, чтение без генерации нод). Невозможно указать несколько свойств на одном правиле (атомарно + не создаёт нод). Pest не генерирует синтаксическое дерево, так что логика парсинга фактически дублируется минимум в двух местах, в грамматике и растовом коде парсера. Текущий парсер не выдерживает изоляцию между слоями логики, так что например компилятор сброда может явно щупать исходные токены, и валиться при расхождении ожиданий. Pest ужасно обрабатывает ошибки, невозможно понять, почему именно правило не подошло.

Итог в том, что малейшие изменения в коде типа "сделать правило неатомарным" или "вместо распознания строки select превратить это в корректный токен SELECT" приводят к каскаду ошибок, которые очень трудно исправлять. Выкинуть целиком текущий парсер и заменить на новую реализацию будет проще, чем пытаться его править инкрементально.

По исходному тикету, пока что действительно лучше ручками поправить ожидаемые пробелы.

Добавлю сюда немного обсуждений из чата, возможно будет полезно для контекста:

• https://t.me/c/1445372156/22633
• https://t.me/c/1445372156/24603

added bug label

added domain/sql triaged labels

changed milestone to %25.2 - Per bucket transactions

mentioned in commit a433bc66

mentioned in commit 3d7090b7

mentioned in merge request !1614

changed milestone to %25.3