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

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(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-03-10 15:32:29
Message-ID: CAKAnmmKzzOWKQVhaAt8LrBmUW=FLWBqS4v8cwKOG53hBToQZRA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Review of v6:

typedef struct partitionNoRecurseNotice
> {
> List *notices;
> } partitionNoRecurseNotice;

Not sure why we need a struct here, rather than just passing the list
around?

Also should be PartitionNoRecurseNotice (CamelCase)

foreach(cell, postNotice->notices)
> {
> if (strcmp((char *) lfirst(cell), notice_msg) == 0)
> {
> pfree(notice_msg);
> found = true;
> break;
> }
> }

This seems a lot of extra work that could be avoided. Since we know each
message is unique to the cmdtype/AlterTableType and the rel/Relation
combination, use those two to drive the duplicate check. Then we can only
build the notice_msg if needed! Perhaps adding two more fields to that
lonely struct above?

partitionNoRecurseNotice * postNotice);

postNotice is a little misleading - maybe pending_notices or just notices?

does not affect present partitions

s/present/existing/g

> CollectPartitionNoRecurseNotice(AT_SetSchema, rel, stmt->relation->inh,
> false, &postNotice);

This hard-coded AT_SetSchema just to return a "SET SCHEMA" later on feels
hacky. Don't have a workaround off the top of my head, just registering my
mild unease. :)

/* Emit a notice only if there are partitions */
> if (nparts == 0)
> return;

It doesn't look like this particular case is tested. Other than that, the
tests look very good.

Cheers,
Greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2026-03-10 16:06:41 Re: Potential security risk associated with function call
Previous Message Robert Haas 2026-03-10 15:22:48 Re: Potential security risk associated with function call