PGConf.Russia 2025

Experience Report addressing the manual migration of MS SQL Server Stored Procedures and Table-Valued Functions to PL/pgSQL. We chose a manual migration from T-SQL over using a PostgreSQL Extension with an automated translation. The motivation was that the T-SQL code contains non-trivial business logic for which we wanted idiomatic PL/pgSQL code. 

The T-SQL Code used features like 

• Mix of Stored Procedures and Table-valued Functions

• Table variables, (user-defined) table types 

• Recursive Common Table Expressions 

• Optional parameters 

The migration required

• Adopting naming conventions 

• Renaming parameters and local variables 

• Maping table types 

• Mapping table-valued parameters to arrays 

• Mapping table-valued return types to SETOF record

• Translating between arrays and tables 

In this session we will migrate a chain of dependend functions T-SQL functions to PL/pgSQL. We will work around quirks in both T-SQL functions and PL/pgSQL.

I’ll talk about the challenges you’ll face if you decide to implement a new TableAM. What to choose: Generic XLog or Custom RMGR? Why use a Custom SMGR? How to integrate PostgreSQL allocators into third-party libraries, even if they don't officially support it? What’s missing for a columnar engine (including vectorization and late materialization), and how can we work around those limitations?

In the second part, I’ll dive into the internals of pgpro_tam — a new native table engine for OLAP that supports standard data formats, various SMGRs, and, if needed, third-party schedulers and execution engines, all while adhering to ACID principles. This is designed to achieve the fastest analytics on PostgreSQL (not just plugging in DuckDB).

In this talk, we’ll:

• Share our experience of reworking the ECM system and platform that was originally built on C.Net + MS SQL for Windows to run on Linux + Postgres, while maintaining the option to install and operate on Windows + MS.

• Discuss migrating clients to new platforms with data migration.

• Share insights from operating the system with a high-load client (PG servers with 192 cores and 3 TB of RAM).

In any business-critical system, there comes a need to modify table structures — whether it's adding new columns with expressions based on other columns or converting a non-partitioned table into a partitioned one.

Using standard PostgreSQL tools for large table reorganization often results in significant downtime, as tables become unavailable for writes — and sometimes even for reads — during the process.

In this talk, I’ll introduce dbms_redefinition, a custom-built extension that brings functionality similar to Oracle’s DBMS_REDEFINITION package to PostgreSQL. This solution minimizes downtime to near zero when applying schema changes in production. 

Unlike pg_repack, which does not support structural modifications, dbms_redefinition is useful for all PostgreSQL users, even beyond Oracle migrations.

I’ll share a real-world use case, discuss future development plans, and explore new features in the pipeline.