В 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

Я как-то рассказывал об одной неочевидной причине, по которой апгрейд версии посгреса может привести к болям в разных частях тела - после 12 версии изменился формат сообщений об ошибках (https://news.1rj.ru/str/nosingularity/875).

Но сегодня всплыл еще один сюрприз:
тип результата функции EXTRACT в 14 версии изменился с double precision на numeric.

И казалось бы, в чем проблема?
Но дальше все зависит от вашего языка и драйвера.
Pg-promise по умолчанию кастит numeric к строке, и в результате вместо ожидаемого инта вы получаете строку, в которой будет число с 16 нулями после запятой.

Дальше, я думаю, понятно...

И я подумал - почему бы не взять все доступные функции и сравнить их сигнатуры от версии к версии. Благо в посгре это можно сделать одним селектом из таблицы pg-proc.
Сказано - сделано!
https://github.com/antonrevyako/postgresql-functions-changes

Справедливости ради, особых откровений в этом сравнении нет:
- в pg12 выкинули типы abstime and reltime, и соответственно все функции с ними.
- в pg12 добавили параметр к функциям конвертации character encoding.
- в pg14 уточнили типа anyarray и any до anycompatiblearray и anycompatible соответственно.
- ну и всякое по мелочи...

Но EXTRACT в этот список не попал :)
В pg-proc не входят функции со специальным синтаксисом, они захардкожены.

Мне когда-нибудь будет не лень и я сравню и все специальные функции тоже...

Еще в процессе тестирования выяснилось, что pg10 ругается, когда пытаешься скастить json-ноду к простому типу, например BOOLEAN, а все версии выше не ругаются.
Энивей, так делать не надо ни в какой версии, поэтому про это будет соответсвующее правило в holistic.dev :)

​Miss me?

It seemed to me that since we did not have the news that you all are waiting for, then I should just be silent.

But some of you are missing my old man jokes, and I decided to break the silence.

I'm still here.
I'm feeling good and located in a safe place if you're asking :)

We almost shipped the first version of column-to-column lineage in dwh.dev and browser plugin for fast cloud providers integration in holistic.dev

So, everything is going on, some great news is coming :)

As you can notice, I decided to try to switch to English. For sure, my graphomaniac texts will lose spectacular humor and charm, but I think that this is the least of what is not a pity to lose in the current situation.