Also a couple other thoughts:
I have a bit of uneasiness about the "use the first hole" method for adding
parents. Namely it makes the whole thing a bit unpredictable from the user's
point of view. The holes aren't user visible so they have no way to know when
they add a parent where in the list of parents it will appear.
And when you add something to a list don't you usually expect it to appear
last? It's not exactly least-surprise compliant to have it appearing in the
middle of the list of parents.
But perhaps it's just worth those downsides to keep DROP/ADD a noop in more
cases.
But on that note I'm starting to have second thoughts about the one-wayness of
attislocal->1. It means if you ever drop a partition all the columns will
become attislocal=1 forevermore, even if you re-add the partition. It also
means if you create partitions independently and then add them they behave
differently from if you create them as inherited tables.
I'm thinking that in the partitioned table use case this will get in the way
of dropping columns from a partitioned table. You'll essentially be forcing
users to drop the column manually from every child.
Maybe it would be better to set attislocal=0 if the attinhcount goes from
0->1?
Otherwise if we don't allow new columns to be created in ADD INHERIT then
we're forcing users to treat all their columns as locally defined.
--
greg