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

Разыскивается С++ Senior! (ну или Middle, который нас приятно удивит)
Мы - Xperience.ai
Специализируемся на компьютерном зрении. Знаем о нем все.
Ты будешь разрабатывать OpenCV с нами.
Мы не удивимся твоим зарплатным ожиданиям, дадим бонусы, ДМС, курсы английского, компенсацию спорта, всё как положено.
Можно работать в нашем офисе в центре Нижнего Новгорода или удаленно.
Почему стоит прийти работать к нам?
Чтобы работать над интересными проектами за большие деньги.
PS: И конечно же у нас дружный коллектив! (а то вдруг тебе дружить не с кем)

Писать сюда: телеграм @lilushonok или на почту lilia.gorlova@xperience.ai

Soooqol, ять…

https://www.cnews.ru/news/top/2021-12-17_rossiyane_sozdali_subdkotoraya

by @sysadmin_tools

Давай по новой, Миша, все фигня! (с)

Кофаундер моих многочисленных стартапов попросил запостить его сообщение без редактирования. Это была битва двух якодзун, и теперь я не могу ничего поделать. Поэтому просто поделюсь его сообщением.

Товарищ Антон будет участвовать в конкурсе Сноуфлейка, где его ждет битва с ордами талантливых, молодых, трудолюбивых индусов, у каждого из которых 1 млн. только друзей детства. Товарищу Антону этот конкурс важен, т.к. результат его весьма повлияет на то, как Сноуфлейк отнесется к его проекту dwh.dev, с которым товарищ Антон к ним планирует прийти в начале 2022 года.
Если вы, уважаемые читатели:
- цените изысканный юмор, которым товарищ Антон вас радует на ежедневной основе, или
- цените его советы, которыми он бескорыстно (зря, но он не слушает) делиться тут и в канале по сноуфлейку, или просто
- уважаете труд, который он вложил в свои проекты, которые он пилит уже который год нон-стоп
То уделите 3 минуту процессу и номинируйте его сами, и друзей попросите. Спасибо!

Что нужно сделать:
- Зайти на community.snowflake.com/s/dataheroes и нажать на большую кнопку NOMINATE A PEER
- В анкете признаться кто вы
- Who are you nominating for the 2022 Data Superheroes?: Anton Revyako
- Why would they make a great Data Superhero?: тут своими словами написать о парсере snowflake диалекта на parsers.dev, lineage на dwh.dev, коммунити и новости в телеге. (В сообщении выше есть ссылки)
- Where are they located?: Eastern Europe
- What is their email address?: anton.revyako@dwh.dev
- Please provide the URL to their LinkedIn profile (if available): https://www.linkedin.com/in/anton-revyako/?locale=en_US

Всем заранее спасибо!

* Часть сообщения дописана copilot'ом :)

топ как по мне

https://gist.github.com/joelonsql/15b50b65ec343dce94db6249cfea8aaa

норм идея.
ровно до того момента, пока FK существует и его можно выбрать однозначно. потом придется переписывать все запросы…

​Итоги года говорят о том, что строить планы на год смысла не имеет. Все всегда идет не так :)

Поэтому всех с НГ, а рефлексировать буду в следующем году!

А вместо пожеланий вот вам нестареющая классика и картинка 10летней давности

Ну, типа, вот...

Snowflake is the DBMS of the Year 2021

Runner-up: PostgreSQL
Third place: MongoDB

https://db-engines.com/en/blog_post/93

Previous winners of the DB-Engines DBMS of the Year Award:

PostgreSQL 2020
MySQL 2019
PostgreSQL 2018
PostgreSQL 2017
Microsoft SQL Server 2016
Oracle 2015
MongoDB 2014
MongoDB 2013

Слышали про duckdb? Это такая OLAP версия SQLite здорового человека.
Казалось бы, куда большим и сложным монстрам до in-memory серверлеса, но тут clickhouse добавили duckdb в свой бенчмарк…

На всякий случай напомню, что существует clickhouse-local, который полноценный кликхаус, но локально на машине и без всяких кластеров и зукипепов.

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