Re: ALTER TABLE: warn when actions do not recurse to partitions - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: ALTER TABLE: warn when actions do not recurse to partitions
Date
Msg-id CAKAnmmKzzOWKQVhaAt8LrBmUW=FLWBqS4v8cwKOG53hBToQZRA@mail.gmail.com
Whole thread
In response to Re: ALTER TABLE: warn when actions do not recurse to partitions  (Jim Jones <jim.jones@uni-muenster.de>)
Responses Re: ALTER TABLE: warn when actions do not recurse to partitions
List 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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Potential security risk associated with function call
Next
From: Matthias van de Meent
Date:
Subject: Re: Potential security risk associated with function call