PGConf.Russia 2025

В докладе расскажем о ручной миграции хранимых процедур и табличных функций из MS SQL Server в PL/pgSQL. Мы сознательно выбрали ручной перевод вместо использования расширений PostgreSQL с автоматической конвертацией. Причина — сложная бизнес-логика в коде T-SQL, для которой мы хотели получить чистый, читаемый PL/pgSQL-код.

В исходном T-SQL коде использовались:

• Комбинация хранимых процедур и табличных функций
• Табличные переменные и пользовательские табличные типы
• Рекурсивные Common Table Expressions (CTE)
• Опциональные параметры

Миграция потребовала:

• Приведения имен к стандартам PostgreSQL
• Переименования параметров и локальных переменных
• Маппинг табличных типов
• Маппинг табличных параметров в массивы
• Маппинг табличных возвращаемых типов в SETOF-запись
• Перевод логики между массивами и таблицами

В докладе мы пройдем путь миграции цепочки зависимых T-SQL-функций в PL/pgSQL, разберем особенности и обойдем подводные камни обоих языков

Каждый день тысячи инженеров прилагают нечеловеческие усилия, чтобы сделать наши данные более достоверными, точными и актуальными. Однако, иногда необходимо поступить наоборот — испортить их. 

Например, скрыть или заменить чувствительные данные, а иногда даже сгенерировать их с чистого листа, сохранив при этом бизнес-свойства данных. Это может понадобиться для тестирования систем, передачи данных третьим лицам и в других случаях. И, оказывается, это тоже достаточно сложная задача (учитывая сложность схемы данных и нетривиальные бизнес-требования).

В докладе рассмотрим основные проблемы искусственных данных и попробуем их решить разными способами, используя встроенные возможности PostgreSQL и сторонние расширения

Расскажу, какие трудности будут на вашем пути, если захотите реализовать новый TableAM. Что выбрать: Generic XLog или Custom RMGR? Зачем Custom SMGR? Как подключить постгресовые аллокаторы в стороннюю либу, даже если она этого вообще не поддерживает? Чего не хватает для колоночного движка (в том числе про векторизацию и позднюю материализацию) и как обойти ограничения?

Во второй части расскажу о внутренностях pgpro_tam — нового нативного табличного движка для OLAP, который поддерживает общепринятые форматы данных, различные SMGR, а если потребуется, то и сторонние планировщики и движки исполнения, находясь в рамках ACID. Всё это для получения самой быстрой аналитики на Postgres (не просто прикрутить DuckDB).

Консолей администратора существует множество — от старорежимного DBeaver до всепроникающего pgAdmin. Тем не менее, мы решили сделать ещё одну. Зачем?

Из доклада вы узнаете:

— Как одна инсталляция может обслуживать несколько десятков тысяч экземпляров БД 

— Сколько пользователей может поддержать консоль 

— Как провести инвентаризацию инфраструктуры и не сойти с ума

— Как вписаться в привычное окружение, не заставляя переделывать всё с нуля

— Как построить модель безопасности, чтобы тебе доверяли ведущие банки и телеком-операторы

— И наконец — как потрогать всё это руками