Комментарии 3
Про TSQL. С одной стороны всё так: и не найти приличных, и в вашем репозитории видно старание, аккуратность и объём проделанной работы, но… Но нельзя просто так взять и написать парсер SQL :)
15 минут посмотрел на лексер и уже вижу не менее 5 ошибок:
Идентификаторы с "[]". Закрывающая скобка может быть частью идентификатора
select 42 as [Look here []]]
Вывод
Look here [] ------------ 42
Числа:
select 1e -- у вас это не число select 1e- -- у вас это не число
- Пустое место. Неразрывный пробел MS SQL воспринимает как пробел. Стоит отметить, что есть и дргие "пробелы"
declare @sql nvarchar(max) set @sql = N'select 1' + char(160) + N'a' print @sql exec (@sql)
BINARY BASE64
воспринимается как одна лексема. Конкретный сценарий неправильного парсинга надо подбирать, но, как минимум, несколько пробелов там допустимы.- Комментарии. У вас `'/' .? '*/', а на самом деле возможны вложенные комментарии.
/* SELECT 'Hello' /* */ SELECT 'Protected by PT' --*/ SELECT 'Executed by someone'
Ваш лексер будет думать, что выведется 'Protected by PT', а на самом деле 'Executed by someone'.
И эти люди защищают нас от инъекций???Простите, не удержался :)
Это правда не более 15 минут просто посмотрев в лексер (комментарий дольше писал). В парсер даже не вчитывался. Я даже не знаю о чем это говорит (выбирайте сами):
- Парсеры без ошибок писать сложно. Чертовски сложно даже для тех, кто, наверное, должен уметь писать безопасные парсеры.
- Язык TSQL — ад для перфекционистов-парсерописателей.
- Open-Source рулит, потому что в закрытом коде эти проблемы просто бы скрылись.
- Я зануда и у меня просто глаз набит (да, я видел очень немного грамматик/парсеров, в которых бы я не находил ошибок).
PS: Правки достаточно простые, я попробую найти время на выходных для PR в github, но не обещаю.
Positive Technologies на GitHub