​Алекс недавно у себя в канале написал пост, что все и так проклято, а люди web3 с метаверсами пилят.

Но все тут собравшиеся знают, что сингулярности не будет :)

Ну не будет и не будет, чего ворчать-то?

Мне тут просто музыкой навеяло...
В ближайшее время на parsers.dev и holistic.dev ожидается релиз mysql/mariadb.
И пока я писал AST-парсер и компилятор, я желал всех благ и здоровья товарищу Монти.

Почему-то постоянно вспоминал смешную статью "Узник замка Фаренгейт":
"Фаренгейту посчастливилось умереть достаточно давно. Будь он жив, к нему бы пришли люди, говорящие с акцентом и убили его арматурными прутьями"

Но это так...
Раздумывая о том какие правила анализатора надо написать в первую очередь, я наткнулся на кеширование запросов.
Нет, не планов запросов, а запросов. Прям побайтово.
Работало это так:
- ключом кеширования является целиком текст запроса. Прям вот с учетом регистра.
- в кеш сохраняется результат выполнения запроса и список таблиц, которые были использованы.
- если какая-то из таблиц обновилась, то кеш очищается.

Прям мем "we have food at home":
- мама, я хочу materialized view!
- materialized view есть у нас дома.
materialized дома: query cache

Там еще много всяких приколов с транзакциями, но это вообще-то и не особо удивительно.
Дальше я случайно наткнулся на кусок исходника, который за это дело отвечает:

https://github.com/twitter-forks/mysql/blob/master/sql/sql_cache.cc#L603

static bool has_no_cache_directive(char *sql)
{
  int i=0;
  while (sql[i] == ' ')
    ++i;
    
  if (my_toupper(system_charset_info, sql[i])    == 'S' &&
      my_toupper(system_charset_info, sql[i+1])  == 'Q' &&
      my_toupper(system_charset_info, sql[i+2])  == 'L' &&
      my_toupper(system_charset_info, sql[i+3])  == '_' &&
      my_toupper(system_charset_info, sql[i+4])  == 'N' &&
      my_toupper(system_charset_info, sql[i+5])  == 'O' &&
      my_toupper(system_charset_info, sql[i+6])  == '_' &&
      my_toupper(system_charset_info, sql[i+7])  == 'C' &&
      my_toupper(system_charset_info, sql[i+8])  == 'A' &&
      my_toupper(system_charset_info, sql[i+9])  == 'C' &&
      my_toupper(system_charset_info, sql[i+10]) == 'H' &&
      my_toupper(system_charset_info, sql[i+11]) == 'E' &&
      my_toupper(system_charset_info, sql[i+12]) == ' ')
    return TRUE;
  
  return FALSE;       
}

https://github.com/twitter-forks/mysql/blob/master/sql/sql_cache.cc#L1490

if ((my_toupper(system_charset_info, sql[i])     != 'S' ||
      my_toupper(system_charset_info, sql[i + 1]) != 'E' ||
      my_toupper(system_charset_info, sql[i + 2]) != 'L') &&
    sql[i] != '/')
{
  DBUG_PRINT("qcache", ("The statement is not a SELECT; Not cached"));
  goto err;
}

На этом, как говорится, мои полномочия все...
А "Узник замка Фаренгейт" вы прочитайте. Смешное.

не все полимеры еще пролюблены…

зачем нужны типы, если string уже придумали

В postgresql 15 (да, осенью будет уже 15 версия, обновитесь уже с вашей 9.6) будут json логи.
нунаканецта! :)

https://www.depesz.com/2022/01/17/waiting-for-postgresql-15-introduce-log_destinationjsonlog/

​Завидую (нет) упорству тех товарищей, которые уверены, что можно написать универсальный парсер (и компилятор) для разных диалектов SQL.

Нет, ну, парсеры бывают разные. Например, парсеры для подсветки синтаксиса: распознаем все знакомые токены и раскрашиваем их в разные цвета.

Следующий этап - распознать похожие на подходящие токены в нужных местах запроса. Тут довольно часто тоже можно срезать углы, но только если у вас нет в планах компилятора или какого-нибудь 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);
select * from identifier($my_table_name);

И режим nighmare - валидирующий парсер.
Это когда синтаксис будет распознан как невалидный по тем же правилам, что и в целевой базе.
Здесь появляются отдельные списки токенов, которые нельзя использовать. Причем, нельзя не везде :)

Например, в 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
-3 + 'a'

В Postgresql все колонки без имени будут назваться '?column?'
В Mysql и Snowflake будет взят исходный код запроса, в нем заменены все переносы строк на пробелы и все приведено к соответствующему регистру - в Mysql к нижнему, в Snowflake к верхнему и будет выглядеть как "1+2 -3 + 'a'"


"Зачем, ты дед, втираешь нам какую-то дичь?", - спросите вы. А я вам скажу. Будьте зайками, не используйте в именах объектов ключевые слова языка. И кавычки тоже.
Это сэкономит много часов дебага.

В holistic.dev, кстати, есть правило, которое вам на это укажет! (playground)

PS: всем кто не любит js, но любит mysql: там строки в математических операциях молча кастятся к нулю.
И делить на 0 можно. NULL получается.
Ладно хоть NULL = NULL это NULL, а не true...

Вышла новая бесплатная книга от postgrespro по внутренностям PostgreSQL

https://postgrespro.ru/education/books/internals

127 окон хватит всем! :)

По мотивам истории с faker.js заметка злого фронтенда про гугл шрифты:

https://news.1rj.ru/str/angry_front_end/20

Пришло письмо от PGConf.Russia
В этом году будет проходить 28 февраля – 01 марта.

Программы пока нет, ждут доклады.

https://pgconf.ru/2022

Комрадс, свершилось!
Начинаю искать сотрудников в holistic.dev

Работать работу. Оплата деньгами.

Прямо сейчас нужны js'еры, кто умеет в типы (ts/flow) и знает про SQL.
Сначала писать будем правила для анализатора.

Т.е. никаких крудов и перекладывания жсонов (хотя, блин, как посмотреть).

Не-js'ры, желающие влиться в наш молодой (кхе-кхе) дедовский коллектив, тоже вэлкам, бэклог на 5 лет вперед, работа найдется :)
Так же нужен будет техпис, который знает про SQL.

Пишите мне в личку @antonrevyako

Помни, лайк и шер повышает стрит кридабилити! :)

Крутейшая новость для тех, кто любит читать пейперы (а именно препринты на arXiv). Если в ссылке на abstract статьи заменить "arxiv" на "ar5iv", то можно читать статью в виде веб-страницы. Тут больше деталей - https://twitter.com/dginev/status/1488157927001268231

Примеры статей:

https://arxiv.org/html/1504.00204 → https://ar5iv.org/html/1504.00204
https://arxiv.org/html/2102.02527 → https://ar5iv.org/html/2102.02527

Час назад выложили плейлист SmartData 2021

https://www.youtube.com/playlist?list=PLeN_80lmoMY37-33D7Jbq09x9wt5BcdBb

Первый раз в жизни был гостем подкаста и мне с первого раза понравилось :)

Поразгоняли про snowflake, статические анализаторы и наш замечательный data lineage продукт dwh.dev

Го слушать :)

https://news.1rj.ru/str/datacoffee/88

PS: если вы работаете со snowflake, но почему-то еще не в наших чатиков, самое время присоединиться:

ru - https://news.1rj.ru/str/snowflakedbchat
en - https://news.1rj.ru/str/snowflakedbchat_en
news - https://news.1rj.ru/str/snowflake_daily

А вот это неплохо:
использовать синтаксис партиционирования, чтобы на балансере сделать из партиций шарды.
Понятно, что про сквозные констрейнты (PK, UNIQUE) можно забыть, но если это не требуется, то звучит интересно…

https://github.com/levkk/pgcat