Re: Support logical replication of DDLs

On Wed, Feb 4, 2026 at 04:39:38PM +0900, Masahiko Sawada wrote:
> On Tue, Feb 3, 2026 at 1:04 AM Vitaly Davydov <v(dot)davydov(at)postgrespro(dot)ru> wrote:
> > 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.
>
> IIUC, one of the main challenges of the "deparsing DDL parse tree"
> idea is the maintenance burden. If we implement logic to deparse parse
> nodes back to SQL text, we would end up updating that deparsing code
> every time the underlying parse node definition changes (which happens
> frequently in internal structures). This introduces a substantial and
> ongoing maintenance cost.

I agree maintenance is the big blocker, but the maintenance is two
parts:

1. writing the patch to adjust for new features in each major release
2. testing the patch

People create some strange database schemas, so testing will be
difficult.

pg_upgrade had a similar challenge, and I found that pushing as much of
the changes _out_ of pg_upgrade and to other parts of the system, e.g,,
pg_dump, was a big help. I am not sure if that is possible for
replicated DDL, but if it is, I would pursue it.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.