Re: DDL deparse

On 6/27/26 09:10, Masahiko Sawada wrote:

> > I guess, for external clients it would be better
> > to receive small simple commands instead of a single complex command.
>
> Could you elaborate on the reason for this point?

When we speak about logical replication clients that are not relational
databases, it would be much easier for developers to implement processing
of received DDL data if it is in a simple and well defined form. If we
replicate an original query like CTAS, it is hard to process such query on
the non rdbms client. Another example - SELECT f(), where f() creates a
number of tables. It is why I assumed that simple DDL queries may be better
for external clients. I'm sorry, I have no other descriptive examples at
the moment.

I'm still not sure, that splitting a single CREATE COMMAND into a number of
simpler commands (like CREATE TABLE, ALTER TABLE ADD COLUMN, ADD INDEX, ADD
CONSTRAINT) may help to developers of non-rdbms clients, but we should not
send original queries to such non rdbms clients in general.

To be honest, I haven't seen any non RDBMS clients that require DDL. It most
cases, "Relation" (R) message from logical replication protocol may be enough.
Not sure, my assumptions are real. It is why I think, that the main use case
for DDL replication is the major upgrage or migration to another RDBMS.

> > CREATE OR REPLACE FUNCTION temp_x () RETURNS void
> > AS $$
> > DECLARE
> > _x integer;
> > BEGIN
> > CREATE TABLE t_b AS SELECT _x;
> > END;
> > $$ LANGUAGE plpgsql;
>
> Thank you for the clarification. If we replicate only the top-level
> DDL, the CREATE TABLE inside the function temp_x() won't be
> replicated.

I guess, it is ok for another postgresql instance, but it doesn't not
work for other types of clients in general, because they do not know
how to process SELECT temp_x().

> > (2) do not replicate (or optionally replicate) some
> > specific settings like toast compression method.
>
> How can we draw a line for settings that are replicated or not replicated?

It is a good question, I can't answer to it completely right now. But, we may
disable replication of settings that belong to the physical storage
configuration, not logical changes in the schema. These settings may be
specific for a particular PostgreSQL major version and will not be applicable
for non RDBMS clients. We may enable replication of such settings optionally,
when needed.

With best regards,
Vitaly