Phase 1: Document current behavior and set expectations
* Identify all ALTER TABLE actions involved in these inconsistencies. * Update the ALTER TABLE and CREATE TABLE documentation to clearly describe the current behavior for partitioned tables, and (where appropriate) the intended or ideal behavior. * Explicitly document the meaning of ONLY for partitioned tables, and note that some actions may behave differently, with details described in each action’s section.
I agree, we should modify alter to note the cascade and/or non-cascade scenarios and modify create to note the things that are (not) inherited. I'm fine with the "newly created" stuff being put into create table instead of touching 5.12.
We should not be documenting "ideal behavior" - only actual behavior.
We should indeed document that ONLY, if added to an alter command that would cascade to partitions, prevents that cascading. If added to a command that wouldn't cascade anyway it is usually accepted as just specifying the default behavior. There is no way to indicate explicitly that one wishes to cascade.
I still have my doubts whether changing long-standing behavior is going to happen. But that is also fairly immaterial since best practice is to proceed without even trying to predict the future and instead just deal with what is in front of us right now.
