Когда говорят «генератор миграций», обычно в голове сразу появляется что-то вроде:

Генератор миграций начинается не с CREATE TABLE, а с вопроса: как представить текущую схему базы в коде?

В первой статье серии разбираем PostgreSQL-first introspector: читаем таблицы, колонки, constraints и индексы, где хватает information_schema, а где приходится идти в pg_catalog, и собираем детерминированный snapshot схемы. Миграции пока не генерируем — строим фундамент, из которого потом можно будет сделать diff и получить DDL.

Статья будет полезна тем, кто пишет инструменты вокруг баз данных, интересуется PostgreSQL internals или хочет понять, почему автомигратор — это не просто набор ALTER TABLE.

Мне нравится чистый SQL.

Не «нравится, потому что пришлось», а правда нравится. В хорошем SQL‑запросе видно, что происходит с данными: откуда берём, как фильтруем, где соединяем, что агрегируем и в каком порядке отдаём наружу.

Но как только в API появляются фильтры, сортировка, пагинация и отдельный COUNT(*) с тем же WHERE, чистый SQL быстро обрастает ручной бухгалтерией: args, placeholder«ы, fmt.Sprintf и копирование условий между запросами.»

В какой‑то момент я понял, что меня раздражает не SQL. Меня раздражает работа вокруг SQL.

Так появился qrafter — небольшой type‑safe SQL query builder для Go: без ORM, без codegen, с типизированными колонками, зависимым от диалекта рендером и обычным SQL + аргументами на выходе.