| 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
| 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 |