Hi Aleksander, >That's great! Thanks!
>Maybe the first implementation shouldn't be perfect as long as known >limitations are documented and the future improvements are unlikely to >break anything for the users. Committing an MVP and iterating on this is >much simpler in terms of development and code review. Also, it will deliver >value to the users and give us feedback sooner. Agree, I’ll post the prototype when it’s in a bit better shape. Also I’d like to hear some more feedback from the community on whether I’m heading the right direction. >I would add DROP TABLE ... CASCADE to the list. Also, let's not forget that >PostgreSQL supports table inheritance and table partitioning. Thanks, I will keep this in mind. >> 1. Database level >> Allows all DDLs for a database to be replicated except for certain >> edge cases (refer to the edge cases mentioned above). >> This is likely a major use case, such as in online major version upgrade. >To my knowledge, this is not a primary use case for logical replication. >Also, I suspect that implementing it may be a bit challenging. What if we >focus on table-level replication for now? I think it is due to the fact that the current limitations in logical replication are holding it back in major version upgrade (MVU). Online / reduced downtime MVU is a popular request from customers, and why we should enhance logical replication to support this use case. Also I think table-level DDL replication is actually more challenging, especially in the FOR TABLE case, due to the fact that differences are expected to occur between the source and target database. Marcos’ comment also justifies the complexity in this case. Whereas database-level DDL replication in the FOR ALL TABLE case is relatively simple because the source and target database are (almost) identical. Regards, Zheng
