​Алекс недавно у себя в канале написал пост, что все и так проклято, а люди 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

+1 графовая база со своим языком. На это раз поверх постгри:

https://www.edgedb.com/blog/edgedb-1-0

video: http://youtu.be/WRZ3o-NsU_4

Концепция делать новые базы поверх существующих хороших баз мне очень нравится :)
Сам планирую одну…

К слову, Firebolt сделан поверх Clickhouse, FerretDB поверх постгри.

​В чатике дата инженеров показали опенсорсную тулзу для lineage.
Мне стало интересно, что даже пришлось ставить богомерзкий питон, чтобы потестить.

Предсказуемо, тулза не понимает специфичного для разных баз синтаксиса, потому что основана на другом опенсорс пакете, который его не понимает.
О чем я и рассказал в этом чатике, позвав всех нуждающихся в lineage для snowflake к нам в dwh.dev

За что мне мгновенно напихали в панамку на тему того, что я скАтина такая, не контрибучу в опенсорс, а посмел сделать что-то лучше, чем есть в опенсорсе, да еще и за деньги (кстати, пока бесплатно).

Так-то оно, конечно, так, но это отличный повод напомнить про мою подборку опенсорс тулзин для SQL :)

https://github.com/antonrevyako/useful-links/blob/master/opensource-sql-tools.md