While working on the patch, I see there are some open questions
1. We decided to pass the conflict history table name during subscription creation. And it makes sense to create this table when the CREATE SUBSCRIPTION command is executed. A potential concern is that the subscription owner will also own this table, having full control over it, including the ability to drop or alter its schema.
...
Typed tables and the dependency framework can address this concern. The schema of a typed table cannot be changed. If the subscription is marked as a dependency of the log table, the table cannot be dropped while the subscription exists.
2. A further challenge is how to exclude these tables from publishing changes. If we support a subscription-level log history table and the user publishes ALL TABLES, the output plugin uses is_publishable_relation() to check if a table is publishable. However, applying the same logic here would require checking each subscription on the node to see if the table is designated as a conflict log history table for any subscription, which could be costly.
Checking the type of a table and/or whether a subscription object depends on it in a certain way would be a far less costly operation to add to is_publishable_relation()
3. And one last thing is about should we consider dropping this table when we drop the subscription, I think this makes sense as we are internally creating it while creating the subscription.
Having to clean up the log table explicitly is likely to annoy users far less than having the conflict data destroyed as a side effect of another operation. I would strongly suggest leaving the table in place when the subscription is dropped.
