MIME-Version: 1.0
References: <OSZPR01MB63102C42A24D59FACF6D9CD6FD4A9@OSZPR01MB6310.jpnprd01.prod.outlook.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> <CAD21AoCzjzr5VqVkpVWkN7V6vrFhac=yXSNMz6rkSE+KOPPU0w@mail.gmail.com>
 <CAExHW5ufb1CAcEP1o03M3c=q6AgCzdSLOFaxbC-dJN-k7ymqaA@mail.gmail.com>
 <38690b0e-f91b-46fa-b72a-57775612e463@postgrespro.ru> <CAD21AoCTdgHGcEQLwbqXR1E6aC1VyO8wOB4S4U6nU50bZQ+NzQ@mail.gmail.com>
 <CAD21AoCzT3sytVbimRNdjRF=N3R-8ddaWKW95EzsdderXqcm4g@mail.gmail.com>
 <CAFiTN-t1d3vzTMy4X=R_9m2AOmyVKpYQWKfZnOrat2voBi-K9g@mail.gmail.com>
 <CAA4eK1LoUyyPGZExMRuhQ2g=_PvpE-NQra-dcE1OF=WeWnURZQ@mail.gmail.com> <CAMT0RQQQ5DAE74GSFnEAtEOGN3tXcXYt==fR1gPZ+PGZD+waPg@mail.gmail.com>
In-Reply-To: <CAMT0RQQQ5DAE74GSFnEAtEOGN3tXcXYt==fR1gPZ+PGZD+waPg@mail.gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
Date: Wed, 29 Apr 2026 09:09:07 +0530
Message-ID: <CAFiTN-vG4z03ar5PMYT3ehe+yzKH8+nPR4uqhNEhnax0DmOq_g@mail.gmail.com>
Subject: Re: Support logical replication of DDLs, take2
To: Hannu Krosing <hannuk@google.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, 
	Vitaly Davydov <v.davydov@postgrespro.ru>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAFiTN-vG4z03ar5PMYT3ehe%2ByzKH8%2BnPR4uqhNEhnax0DmOq_g%40mail.gmail.com>
Precedence: bulk

On Wed, Apr 29, 2026 at 1:25=E2=80=AFAM Hannu Krosing <hannuk@google.com> w=
rote:
>
> My high-level understanding is, that we should first clearly answer these=
 two questions
>
> 1. What does Logical Decodng infrastructure make available to the decodin=
g plugin call-backs
>
> 2. What the callbacks themselves do in case of DDL

Yeah that makes sense, Hannu.

> My answer to the 1. is "everything, as it should be the plugin that decid=
es what it needs". It does not mean that we should always prepack everythin=
g with special logical decoding structures, but there should be a way to ge=
t at anything that is available in the WAL at least. The result is in WAL, =
and for DDL it is also in the system tables themselves, in proper time-trav=
el way.
>
> For 2. I would prefer to "deparse" the DDL from actual system tables at t=
hat snapshot. In logical decoding the system tables are special in that we =
keep the actual table content and have real time travel capabilities on the=
m. This should allow us to use the code we already have in pg_dump for extr=
acting the "status quo DDL" meaning the DDL for creating everything from sc=
ratch. The main thing missing is DDL for ALTER and DROP which would need to=
 be added. But that too should be in the plugin, not in the DDL side .

I am trying to understand your idea. If we are trying to deparse from
an actual system table using a snapshot, why don't we just use the
WAL? I mean, the WAL should contain the actual catalog modifications
it has made.  Although converting the catalog changes into a deparse
representation of the DDL could be complex no?  Another question is
what we would do with those deparsed representations: will we convert
them to SQL on the subscriber and execute, or do something else?

--=20
Regards,
Dilip Kumar
Google