парсер sql на питоне

Разве всякие ОРМ не про это? Например, Function-based query construction?

Специально для этого есть views. Но если имеется «скажи нет любой логике в БД» в тяжелой стадии, то только свой парсер

Чем только люди не занимаются, лишь бы кодревью не делать.

where ... limit ...

А потом при дебагe он сношает себе мозги на тему, почему не все записи возвращаются?

почему не все записи возвращаются?

в этом весь смысл.

только свой парсер

ну как свой, есть наверно пяток питоничих либ, рекомендованных к использованию?

Это чтобы вебмакаки себе всю базу в мильярд записей не вывернули.

Сам никогда такого не встречал. Хотя задача довольно часто в головах рождается, но вот чтобы оно работало нормально и не ломалось от того, что вместо limit написано FETCH NEXT 10 ROWS ONLY(это pg), я не видел. Больше с таким не заморачиваюсь - sql в этом плане УГ ещё то

смысл не пререгружать канал передачи данных?

тк база ложиться и от возврата одной записи вполне:

select count(*) from ( select * from bigone, bigone ) _

вот и я говорю: select from select тоже неплохо бы кошерно разобрать и дополнить.

лексические парсеры обычно пишут на yacc. парсер sql для yacc написан, реализация yacc для бидона вроде как тоже.

вариант кажется рабочим, но сам ничем таким не занимался

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

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

в этом весь смысл.

В чём? Заставить джуна потрахаться и уверовать в свою неполноценность?

я тут как?

select count(*) from ( select * from bigone b join ... ) x
where x.fld < value

т.е. оно будет ломать запросы

относительно pg думаю задача нереальная, т.к. with, lateral, unnest и другие прелести.

оно будет ломать запросы

where x.fld < value and ....

понятно что юзкейсы надо отрабатывать, тут попробовать бы хоть на пароке запросов.

относительно pg думаю задача нереальная

это еще очень далеко, тут просто select бы порезать.

Заставить джуна потрахаться и уверовать в свою неполноценность?

ну например.

так ты знаешь способ или нет? :)

SQLITE + https://sqlite.org/vtab.html

Если кратко, то все это работает так.

Имеется parser и run-time SQL, которая будет «дергать» функции из вашего расширения.
При желании можете обеспечить SQL запросы к ЛЮБОМУ набору данных.

Например у меня таким образом обеспечены полноценные SQL запросы к DBF + CDX /ну «нужно было»/.

На счет «на питоне», то пишется это все на С или C++.
Потом пишете binding и радуетесь.

Из описания в треде следует что вам нужно свое подмножество SQL, и ни один чужой велосипед для этой задачи не подойдет.

Делается это так.
Порт, который использует СУБД берете под свой контроль.
Конечно вы должны понимать протокол, используемый СУБД.

пока это самое красноглазое красноглазие из всего предложенного красноглазого красноглазия в треде.

Это мера против обезьянок или против аналитиков?

https://github.com/mozilla/moz-sql-parser

и не спрашивай, с какой целью я использовал этот проект)))

во ввымя sso

гугл пометил как «посещенный», но там надо пилякать :(

Очень странное хотение. Особенно странное, если нужно под несколько субд.

Закрыть доступ к БД и поднять микросевис?

пользователь пишет select * from table, а мы ему заботливо добавляем where ... limit ...

Надо избавиться от select * from table и заменить его какой-нибудь структурой, из которой будет потом сварен sql. Юзеру объяснить, что это такая фича. Парсить sql со всеми его подзапросами, диалектами, with, функциями, join'aми дело сомнительное. Кто-нибудь да сломает этот парсер.

Порт, который использует СУБД берете под свой контроль.

Стоите на порту, рычите и тазом двигаете?

Абстрагировать все SQL либо в ORM либо вообще в API. Нефиг пользователю давать в базу лезть.