Date: Thu, 12 Feb 2026 17:12:02 -0500
From: Bruce Momjian <bruce@momjian.us>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Vitaly Davydov <v.davydov@postgrespro.ru>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Support logical replication of DDLs
Message-ID: <aY5QMkm8xHnU32M_@momjian.us>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAD21AoCzjzr5VqVkpVWkN7V6vrFhac=yXSNMz6rkSE+KOPPU0w@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aY5QMkm8xHnU32M_%40momjian.us>
Precedence: bulk

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.davydov@postgrespro.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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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