On Mon, Feb 4, 2019 at 11:30 AM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > If you do ALTER TABLE .. REPLICA IDENTITY to a partitioned table, the > command operates on the parent table itself and does not propagate to > partitions. Why is this? Maybe not recursing was the right call when > we only had regular inheritance (back in 9.4), but since partitioned > tables got introduced, I think it is completely the other way around: > not recursing is an usability fail.
This sounds an awful like the TABLESPACE case. I wonder how many more similar things there are. It's not unreasonable to use the parent's REPLICA IDENTITY setting as the default for new partitions, much as we now do for the TABLESPACE, because the parent's replica identity is otherwise without meaning. But I'm less convinced that it's reasonable to have changing the parent's replica identity recurse to existing children, because: 1. That's different from the TABLESPACE case. We shouldn't just treat each new instance of this problem as a green field where we can pick any old behavior at random; it should be consistent as far as reasonable, and 2. It confuses a change to the default for new partitions with a change to the value for existing partitions. Say that you've got 5 existing partitions that use one setting, but now you want new partitions to use a different setting. You can't get that with your proposed semantics, because trying to change the default will change all the existing partitions to the new value also, even though that's not what you wanted. We should really, really try to figure out all of the things that are like this -- a property that is meaningless for the partitioned table itself but may serve as a useful default for its children -- and try to make them all work the same, ideally in one release, rather than changing them at different times, back-patching sometimes, and having no consistency in the details. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
