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
