Re: Support logical replication of DDLs, take2

On Wed, Apr 29, 2026 at 3:19 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Mon, Apr 27, 2026 at 11:32 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > Yes, there will be a maintenance cost of JSON-based deparsing
> > approach. But note that multiple senior people (Alvaro Herrera, Robert
> > Haas) [1] seems to favor that approach. So, I am not sure we can
> > conclude to abandon that approach without those people or some other
> > senior people agreeing to abandon it. To be clear, I am not against
> > considering a new/different approach for DDL replication but just that
> > it is not clear that old/existing approach can be ruled out without
> > more discussion on it,
>
> Thank you for pointing it out. Just to be clear, IIUC what they liked
> was to use JSON string representation of DDLs, but not JSON string
> representation of DDLs that are deparsed from parse nodes, no?
>

As per my understanding, we built deparsing stuff with a goal of
supporting DDL replication and Alvaro was the original author of that
work, see [1]. The benefit it provides flexibility in terms of
filtering by decoding plugin, if any, or changing the DDL (like
schema-mapping) during apply. It is not clear to me if we can achive
similar level of flexibility with other approach.

>
> >
> > We would need to maintain the JSON serialization code whenever
> > > creating or modifying parse nodes, regardless of whether the changes
> > > were related to DDL replication. IIUC, this was the primary reason the
> > > feature didn't cross the finish line.
> > >
> > > Additionally, I think there is another design issue: it is not
> > > output-plugin agnostic. Since the deparsed DDL was written by a
> > > logical-replication-specific event trigger, third-party logical
> > > decoding plugins cannot easily detect DDL events.
> > >
> >
> > Why RmgrId like RM_LOGICALDDLMSG_ID and XLOG_LOGICAL_DDL_MESSAGE wal
> > info is not sufficient for this? Decoder will add a message like
> > REORDER_BUFFER_CHANGE_DDL which can be used to detect DDL message, no?
>
> Right, but I'm not sure this is a good developer experience that
> additional steps are required to capture DDL events for other plugins
> while changes of INSERT/UPDATE/DELETE/TRUNCATE are passed from the
> logical decoding by default.
>

Yes, there could probably be additional steps for plugins but they
must be doing a few things already which are defined at publication
level like column lists, row filtering, something related to RI, etc.
To reduce the plugin work, one naive idea is to let the event triggers
be registered at first logical slot creation or may be at init time of
plugin.

[1]: https://www.postgresql.org/message-id/202203162206.7spggyktx63e%40alvherre.pgsql

--
With Regards,
Amit Kapila.