> 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
