> I am not if it's feasible to support the use case the replicate DDL to old > subscriber. >
+1 > First, I think the current publisher doesn't know the version number of > client(subscriber) so we need to check the feasibility of same. Also, having > client's version number checks doesn't seem to be a good idea. > > Besides, I thought about the problems that will happen if we try to support > replicating New PG to older PG. The following examples assume that we > support the DDL replication in the mentioned PG. > > 1) Assume we want to replicate from a newer PG to a older PG where > partition > table has not been introduced. I think even if the publisher is aware of > that, it doesn't have a good way to transform the partition related > command, > maybe one could say we can transform that to inherit table, but I feel that > introduces too much complexity. > > 2) Another example is generated column. To replicate the newer PG which > has > this feature to a older PG without this. I am concerned that is there a way > to transform this without causing inconsistent behavior. > > Even if we decide to simply skip sending such unsupported commands or > skip applying them, then it's likely that the following dml replication will > cause data inconsistency. > > So, it seems we cannot completely support this use case, there would be > some limitations. Personally, I am not sure if it's worth introducing > complexity to support it partially. > +1 Regards Sachin
