Message-ID: <080f9394-c127-4cef-865e-10f2f997125c@postgrespro.ru>
Date: Mon, 2 Feb 2026 19:04:32 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Support logical replication of DDLs
To: 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>
Content-Language: en-US
From: Vitaly Davydov <v.davydov@postgrespro.ru>
In-Reply-To: <CAA4eK1JpAcvnfOqF2DQo79pf7Cqp5=3HU5UDwBonWXW4V9ot=w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/080f9394-c127-4cef-865e-10f2f997125c%40postgrespro.ru>
Precedence: bulk

Dear Hackers,

I see, that the primary idea in this thread is to capture DDL statements with
the use of the utility hook, convert it into a json-like format, save it in the
WAL (xl_logical_message) and send it to a peer using the logical replication
subsystem (walsender). This approach has a major challenge that was already
highlighted: DDL statements may be too complex to convert it into a json string
(for example, unlogged/temporary objects in DDL statements).

An alternative approach, that was highlighted in the discussion by Dilip Kumar
is to decode system catalog changes. It helps to deal with complex DDL
statements containing temp objects and to work with a final representation of
changes stored in the WAL. Personally, I like this approach.

I would share the following idea:

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.

The open question: can we unambiguously decode system catalog changes?

I would appreciate any feedback.

With best regards,
Vitaly