Re: docs: clarify ALTER TABLE behavior on partitioned tables

> On Jan 10, 2026, at 00:12, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Fri, Jan 9, 2026 at 1:11 AM Chao Li <li.evan.chao@gmail.com> wrote:
> >
> > The main points of interest:
> >
> > Saying that "ONLY" is a no-op when the observed behavior is that only the mentioned tables are affected seems
wrong. I've removed those instances. 
>
> Maybe the original phrasing “has no effect” wasn’t clear for what I meant. What I was trying to express is that ONLY
isintended to control whether an action propagates to child tables: with ONLY it should not propagate, and without ONLY
itshould. 
>
> For these particular sub-commands, however, the observed behavior is that they behave the same with or without ONLY.
Froma documentation perspective, stating that explicitly could help avoid user confusion. 
>
> Separately, I do have a plan to tighten this behavior in the future: for these commands, specifying ONLY would raise
anerror instead. If such a change is merged later, the documentation note could naturally be removed at that point. 
>
> So I’d like to keep the statement for now, but I’m very happy to adjust the wording if you have a clearer phrasing to
suggest.
>
> I've removed some I missed and tweaked others.  I'm OK with leaving mention of ONLY in these sections but what
happensis that ONLY becomes implicitly added to the command, which is what I'd rather communicate.  The remaining
wordingis a bit redundant now but flows nicely. 

Changing the phrase “has no effect” to “implicitly” looks good to me. ONLY is implicit on the following sub-commands:

 * SET/RESET (attribute_option = value)
 * ENABLE/DISABLE [ REPLICA | ALWAYS] RULE
 * ENABLE/DISABLE ROW LEVEL SECURITY
 * NO FORCE / FORCE ROW LEVEL SECURITY
 * OWNER TO
 * REPLICA IDENTITY
 * SET SCHEMA
 * SET COMPRESSION
 * SET TABLESPACE
 * OF type
 * NOT OF
 * RENAME

I saw you removed “ONLY” statement from some of them and changing “has no effect” to “implicit” on rests. So, I just
wantto confirm if you intentionally removed those or just missed changing them? 

>
> Before I integrate your edits and prepare v3, I’d appreciate hearing your thoughts on the points about ONLY and
“newlycreated”. 
>
>
> As I continue to think about the "newly created" material the more I believe it is misplaced.  That there is existing
wordingto that effect doesn't change my conclusion.  I would add no additional text here even if you don't want to
removethe existing mentions at this point.  But I think the scope of this patch should be increased to fix this
misplacementas well.  Since moving content - refactoring - is what is happening here.  In the attached 0003 I've
removedthe paragraphs that this patch now makes redundant within the alter table documentation.  I wouldn't mind if
theygot moved to somewhere in Chapter 5.12 (Table Partitioning) and not just erased, along with ensuring that 5.12
includeshow table creation  definition inheritance works and removing those mentions from the alter table docs as well. 

A new partition automatically inheriting the parent’s setting is an expected behavior, and most of sub-commands meet
theexpectation. So I’m fine to remove the “newly created” material from these “good" sub-commands. 

Only a few sub-commands break the expectation, they are:

 * SET STATISTICS
 * SET/RESET (attribute_option = value)
 * ENABLE/DISABLE [ REPLICA | ALWAYS] RULE
 * ENABLE/DISABLE ROW LEVEL SECURITY
 * NO FORCE / FORCE ROW LEVEL SECURITY
 * OWNER TO
 * REPLICA IDENTITY
 * SET SCHEMA

The current behavior (not inherit) is questionable, we will need separate discussions for each of them to clarify if
that’sintended or “bugs”. So, how about only retain the “newly created” material for these sub-commands and remove from
therests? In this case, I don’t think we need to update 5.12.   

What I am thinking is that, we will eventually remove the “newly created” material from these sub-commands, because
nextstep we are going to fix the behavior on them one by one. Maybe some of them are designed to not “inherit the
parent’ssetting”, then we can add a paragraph/section to 5.12 to describe that. 

>
> I'm not sure whether I'd fully remove all that content since some of it does pertain just to table inheritance.  That
featureseems like something best related to notes and not brought into the main flow like you are doing with
partitionedtables. 
>
> David J.
>
>
>
<v2-0001-docs-Clarify-ALTER-TABLE-v1.patch><v2-0003-docs-ONLY-tweaks-and-bulk-note-removal.patch><v2-0002-docs-Clarify-ALTER-TABLE-v1-edits.patch>

--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/