On Wed, Feb 4, 2026 at 04:39:38PM +0900, Masahiko Sawada wrote: > On Tue, Feb 3, 2026 at 1:04 AM Vitaly Davydov <[email protected]> > 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 <[email protected]> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
