Re: ALTER TABLE: warn when actions do not recurse to partitions

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: ALTER TABLE: warn when actions do not recurse to partitions
Date: 2026-01-23 09:57:48
Message-ID: f4f70647-8738-48b3-abbd-5b52cde97374@uni-muenster.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-01-23 10:03:33 Re: Remove PG_MMAP_FLAGS
Previous Message Eugeny Goryachev 2026-01-23 09:41:03 [PATCH] Avoid potential NULL dereference in LIKE/ILIKE with C locale