Smartface, technologies and decay
@antonrevyako
Post #959
2.33K
Завидую (нет) упорству тех товарищей, которые уверены, что можно написать универсальный парсер (и компилятор) для разных диалектов SQL.
Нет, ну, парсеры бывают разные. Например, парсеры для подсветки синтаксиса: распознаем все знакомые токены и раскрашиваем их в разные цвета.
Следующий этап - распознать похожие на подходящие токены в нужных местах запроса. Тут довольно часто тоже можно срезать углы, но только если у вас нет в планах компилятора или какого-нибудь intellisense.
Внезапно различия начинаются прямо на этапе описания идентификаторов.
В Postgresql имена таблиц и колонок можно записать как table1, Table1 и "Table1". Первые два будут приведены к одному виду (в нижний регистр), а для обращения к последнему нужно будет и дальше брать в кавычки и соблюдать регистр. Одинарные кавычки будут ошибкой.
В Snowflake table1 и Table1 будут приведены к верхнему регистру, для регистрозависимого имени нужно будет так же указать имя в двойных кавычках.
Можно еще задать имя в обратный одинарных кавычках - `
В Mysql table1 и Table1 будут РАЗНЫМИ объектами, а `
Да, еще в Mysql можно начинать имя с $, нигде такого безобразия нет.
В Postgresql и Mysql имена объектов можно указывать не только латинскими буквами, но и кириллическими.
А в Snowflake нет.
Но зато там есть такая конструкция как identifier:
Это когда синтаксис будет распознан как невалидный по тем же правилам, что и в целевой базе.
Здесь появляются отдельные списки токенов, которые нельзя использовать. Причем, нельзя не везде :)
Например, в Snowflake ключевое слово LIMIT - не ключевое слово и его можно использовать как алиас. Во всех базах такое не пройдет:
Еще есть отдельный список того, что нельзя использовать в качестве имен таблиц.
Отдельный список того, что нельзя использовать в качестве имен колонок.
Но не всегда. Иногда можно.
Например, в Snowflake CONSTRAINT может быть именем поля, но только в кавычках. А CURRENT_DATE не может даже в кавычках.
Но это имена полей. Именами таблиц и то и то может быть даже без кавычек...
А в Mysql можно ключевые слова использовать как имена полей, если взять их в обратные кавычки:
В Postgresql и Snowflake можно и так и так...
С компиляторами, кстати, тоже отличная история.
В Snowflake и Clickhouse можно переиспользовать алиасы в рантайме:
Mysql важно в каком регистре написаны имена таблиц, но на колонки в этом случае почему-то наплевать: table1.field1 и table1.Field1 это одно и то же.
Очень удобно.
Неименованные динамические колонки так же работают по-разному:
В Mysql и Snowflake будет взят исходный код запроса, в нем заменены все переносы строк на пробелы и все приведено к соответствующему регистру - в Mysql к нижнему, в Snowflake к верхнему и будет выглядеть как "1+2 -3 + 'a'"
"Зачем, ты дед, втираешь нам какую-то дичь?", - спросите вы. А я вам скажу. Будьте зайками, не используйте в именах объектов ключевые слова языка. И кавычки тоже.
Это сэкономит много часов дебага.
В holistic.dev, кстати, есть правило, которое вам на это укажет! (playground)
PS: всем кто не любит js, но любит mysql: там строки в математических операциях молча кастятся к нулю.
И делить на 0 можно. NULL получается.
Ладно хоть NULL = NULL это NULL, а не true...
Нет, ну, парсеры бывают разные. Например, парсеры для подсветки синтаксиса: распознаем все знакомые токены и раскрашиваем их в разные цвета.
Следующий этап - распознать похожие на подходящие токены в нужных местах запроса. Тут довольно часто тоже можно срезать углы, но только если у вас нет в планах компилятора или какого-нибудь intellisense.
Внезапно различия начинаются прямо на этапе описания идентификаторов.
В Postgresql имена таблиц и колонок можно записать как table1, Table1 и "Table1". Первые два будут приведены к одному виду (в нижний регистр), а для обращения к последнему нужно будет и дальше брать в кавычки и соблюдать регистр. Одинарные кавычки будут ошибкой.
В Snowflake table1 и Table1 будут приведены к верхнему регистру, для регистрозависимого имени нужно будет так же указать имя в двойных кавычках.
Можно еще задать имя в обратный одинарных кавычках - `
table1`. Оно приведется к верхнему регистру, а кавычки останутся частью имени. В Mysql table1 и Table1 будут РАЗНЫМИ объектами, а `
table1` будет равен table1. Одинарные и двойные кавычки будут ошибкой.Да, еще в Mysql можно начинать имя с $, нигде такого безобразия нет.
В Postgresql и Mysql имена объектов можно указывать не только латинскими буквами, но и кириллическими.
А в Snowflake нет.
Но зато там есть такая конструкция как identifier:
create table identifier($my_table_name) (i integer);И режим nighmare - валидирующий парсер.
select * from identifier($my_table_name);
Это когда синтаксис будет распознан как невалидный по тем же правилам, что и в целевой базе.
Здесь появляются отдельные списки токенов, которые нельзя использовать. Причем, нельзя не везде :)
Например, в Snowflake ключевое слово LIMIT - не ключевое слово и его можно использовать как алиас. Во всех базах такое не пройдет:
select * from t as limit limit 1А в Snowflake все ок.
Еще есть отдельный список того, что нельзя использовать в качестве имен таблиц.
Отдельный список того, что нельзя использовать в качестве имен колонок.
Но не всегда. Иногда можно.
Например, в Snowflake CONSTRAINT может быть именем поля, но только в кавычках. А CURRENT_DATE не может даже в кавычках.
Но это имена полей. Именами таблиц и то и то может быть даже без кавычек...
А в Mysql можно ключевые слова использовать как имена полей, если взять их в обратные кавычки:
create table t(`limit` integer);Но в запросе
select limit from t;так нельзя, а так
select t.limit from t;уже можно :)
В Postgresql и Snowflake можно и так и так...
С компиляторами, кстати, тоже отличная история.
В Snowflake и Clickhouse можно переиспользовать алиасы в рантайме:
select 1 as a, a + 1 as bа в Postgresql и Mysql нет.
Mysql важно в каком регистре написаны имена таблиц, но на колонки в этом случае почему-то наплевать: table1.field1 и table1.Field1 это одно и то же.
Очень удобно.
Неименованные динамические колонки так же работают по-разному:
select 1+2В Postgresql все колонки без имени будут назваться '?column?'
-3 + 'a'
В Mysql и Snowflake будет взят исходный код запроса, в нем заменены все переносы строк на пробелы и все приведено к соответствующему регистру - в Mysql к нижнему, в Snowflake к верхнему и будет выглядеть как "1+2 -3 + 'a'"
"Зачем, ты дед, втираешь нам какую-то дичь?", - спросите вы. А я вам скажу. Будьте зайками, не используйте в именах объектов ключевые слова языка. И кавычки тоже.
Это сэкономит много часов дебага.
В holistic.dev, кстати, есть правило, которое вам на это укажет! (playground)
PS: всем кто не любит js, но любит mysql: там строки в математических операциях молча кастятся к нулю.
И делить на 0 можно. NULL получается.
Ладно хоть NULL = NULL это NULL, а не true...
