Message-ID: <f4f70647-8738-48b3-abbd-5b52cde97374@uni-muenster.de>
Date: Fri, 23 Jan 2026 10:57:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: ALTER TABLE: warn when actions do not recurse to partitions
To: Chao Li <li.evan.chao@gmail.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
 Greg Sabino Mullane <htamfids@gmail.com>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
References: <CAEoWx2=SLga-xH09Cq_PAvsHhQHrBK+V0vF821JKgzS=Bm0haA@mail.gmail.com>
 <CAKFQuwZXt2dAuHFs6MtRCzfMP6YZFzssuzdW2woJBVmco=CDdQ@mail.gmail.com>
 <CAEoWx2nic2MaPUEKwb0Me1iwO3LsCf8wUHm55pjqaTRgJEZpcQ@mail.gmail.com>
 <CAKFQuwahxpPKT-LXGJ34BO5cVBUxFxzgNPTY8E_VW-cuNU_DkQ@mail.gmail.com>
 <CAEoWx2kQ9aSn-0LGPKc=woj+h-HR4uBV9TL20aeM3HzLmFqgFQ@mail.gmail.com>
 <6eff5e43-cacd-4a2a-ad1d-e3b313c86050@uni-muenster.de>
 <950BB7B5-0180-4C36-82A0-7E17B920F740@gmail.com>
 <CAEoWx2mZsWnyS_XLDL5mL+yuU_g65p_tmHNesyfngqow7gtS3A@mail.gmail.com>
 <fb70022a-5403-4e16-9efc-28b041f35d9a@uni-muenster.de>
 <8ECD9403-F0BB-4971-94CF-2709EEB4E3B9@gmail.com>
Content-Language: de-DE, en-GB
From: Jim Jones <jim.jones@uni-muenster.de>
In-Reply-To: <8ECD9403-F0BB-4971-94CF-2709EEB4E3B9@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/f4f70647-8738-48b3-abbd-5b52cde97374%40uni-muenster.de>
Precedence: bulk


On 23/01/2026 01:11, Chao Li wrote:
> I will wait to see the test results and address all issues together in next version.

While testing some edge cases I found out that the NOTICE is being
emitted too early in the code path, e.g.

postgres=# ALTER TABLE m ALTER COLUMN b SET COMPRESSION pglz;
NOTICE:  ALTER action ALTER COLUMN ... SET COMPRESSION on relation "m"
does not affect present partitions
HINT:  partitions may be modified individually, or specify ONLY to
suppress this message
ERROR:  column data type integer does not support compression

I'd argue that emitting only the ERROR message in this case would be the
right approach. What about moving the EmitPartitionNoRecurseNotice()
call to ATExecCmd, right **after** the changes were successfully
executed? For instance, in the case I mentioned above, you could explore:

@@ -5446,6 +5475,8 @@ ATExecCmd(List **wqueue, AlteredTableInfo *tab,
                case AT_SetCompression: /* ALTER COLUMN SET COMPRESSION */
                        address = ATExecSetCompression(rel, cmd->name,
cmd->def,

          lockmode);
+                       /* Emit notice after validation passes */
+                       EmitPartitionNoRecurseNotice(cmd->subtype, rel,
cmd->recurse, false);
                        break;

Not sure if cmd->recurse is propagated in this code path. If not, you
might need to do it manually, e.g.

@@ -4936,6 +4937,14 @@ ATPrepCmd(List **wqueue, Relation rel,
AlterTableCmd *cmd,
         */
        cmd = copyObject(cmd);

+       if (recurse)
+               cmd->recurse = true;
+

I'm not saying it should be exactly this way, but it sounds more
reasonable to me to emit the NOTICE only if we know that the command is
going to be successfully executed (or was successfully executed).

This patch touches a lot of regression tests, but mostly to add the
keyword ONLY to the ALTER TABLE statements, to avoid the NOTICE message,
so that's ok.

Thanks!

Best, Jim