Re: docs: clarify ALTER TABLE behavior on partitioned tables

> On Mar 30, 2026, at 03:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> writes:
>> PFA v10 - just integrated v9-0002-diff into the patch.
>
> I do not like this patch *at all*. It removes the documentation
> that enunciates the general principles ALTER is following, such as
>
> - If a table has any descendant tables, it is not permitted to add,
> - rename, or change the type of a column in the parent table without doing
> - the same to the descendants. This ensures that the descendants always
> - have columns matching the parent. Similarly, a <literal>CHECK</literal>
>
> and replaces that with highly repetitive, explanation-free
> statements like "Specifying <literal>ONLY</literal> is not allowed"
> for each option. I don't see how this set of changes is an improvement.
> It's also close to unreviewable, since it's so hard to see whether
> those statements have been attached to all and only the proper
> options.
>
> If there's mistakes in the existing text, by all means let's fix
> them. But this doesn't seem like the way to go about it.
>
> By the by, I believe that our general project style is to leave a
> blank line between <para> units. So I also don't approve of the
> patch making a concerted effort to remove a lot of those blank
> lines, especially when it's doing that to just one file.
>
> regards, tom lane

Hi Tom,

Thanks for your comments.

The main goal of this patch is to clarify how ALTER TABLE sub-commands behave on partitioned tables, since the current behavior is not always consistent or easy to predict. Because of that, some per-subcommand verification is probably unavoidable. But I agree the current patch may make that harder than it should be.

I also was not aware of the blank-line style convention. In any case, that part is easy to fix.

I’ll rework the patch to better address your concerns.

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