Message-ID: <cfca4aa4-b951-4c5a-b7d5-49018ab4fc57@proxel.se>
Date: Mon, 9 Feb 2026 14:40:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Support logical replication of DDLs
To: Vitaly Davydov <v.davydov@postgrespro.ru>,
 pgsql-hackers@lists.postgresql.org
References: <OSZPR01MB63102C42A24D59FACF6D9CD6FD4A9@OSZPR01MB6310.jpnprd01.prod.outlook.com>
 <OS3PR01MB6275328379FBE5734B4585619E54A@OS3PR01MB6275.jpnprd01.prod.outlook.com>
 <ZIgf3qBvFoTsMhIc@paquier.xyz>
 <CAA4eK1J8WOK9VZ9RpQRNRhRYhFOKQCu=GLCu+iBOePNO3JwLbQ@mail.gmail.com>
 <ZIjmGhPWdoJUfjjE@paquier.xyz>
 <CAJpy0uDaubBHyqPc1k0OysuBYDOVdoUgTWG4jXDCYj-OVSU8hg@mail.gmail.com>
 <CAA4eK1+K8KMsB=+jJO6wDUSt7wF1RiXKtF-HN48nCOEOv-J-3Q@mail.gmail.com>
 <CAJpy0uDLLBYAOzCePYObZ51k1epBU0hef4vbfcujKJprJVsEcQ@mail.gmail.com>
 <CAJpy0uAhLjQZ0Dh0KWDFP8mrnG0rbx99_heavwn8Ke8ZuD-Umg@mail.gmail.com>
 <OS0PR01MB5716A47D23EFAF988475D4A99431A@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <CAD21AoCXCAQ5QyXu9-xs30ViUHtUxQMmf-818d8GX--5pTmZ7g@mail.gmail.com>
 <OS0PR01MB57163E6487EFF7378CB8E17C9438A@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <B38B7239-92B0-4212-A8BF-FE506C3B0F66@yandex-team.ru>
 <CAA4eK1JpAcvnfOqF2DQo79pf7Cqp5=3HU5UDwBonWXW4V9ot=w@mail.gmail.com>
 <080f9394-c127-4cef-865e-10f2f997125c@postgrespro.ru>
From: Andreas Karlsson <andreas@proxel.se>
Content-Language: en-US
In-Reply-To: <080f9394-c127-4cef-865e-10f2f997125c@postgrespro.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/cfca4aa4-b951-4c5a-b7d5-49018ab4fc57%40proxel.se>
Precedence: bulk

On 2/2/26 5:04 PM, Vitaly Davydov wrote:
> 1. Log into the WAL system catalog changes (tuples) suitable for logical
> decoding (introduce a new wal_level = logical_ddl). I think, not all system
> catalog changes are needed for decoding (not sure, we have to decode 
> pg_depend
> changes).
> 
> 2. Implement a decoder of system catalog changes, that can produce a 
> parse tree
> using existing structures from parsenodes.h.
> 
> 3. Based on the decoded parse tree, we can convert it into json or DDL SQL
> statements in the output plugin. ParseTree to DDL SQL converter can be 
> built-in
> into the core. Output plugin can decide which converter to use. DDL sql 
> can be
> directly applied on the replica.
> 
> 4. Another option is to create json/ddl-sql from system catalog changes 
> without
> an intermediate representation, but, anyway, when we interpret system 
> catalog
> changes we have to temporary save current data in some structures. 
> Parsenodes
> is the already existing solution for it.

With this approach how do you intend to handle DDL changes which alter 
data? To take a simple case we have the USING clause when altering a 
column. Maybe it is a fine limitation to just not support it but I am 
not convinced.

Andreas