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.
