Hey Alberto, > Besides this specific problem: there are currently multiple active > threads related to bugs with recursive alter table. I would suggest > specifically to read through [0], all of it because v19 is very > different than v1. The patch coming out of that thread partially > overlaps with this one. It tries to fix properties being lost in > recursive alter table operations that cause index rebuilds, both > properties which could be recreated with alter table commands and > properties which couldn't.
Thanks for the review, and for the suggestion, I'll definitely take a look at that discussion. At first glance it looks very relevant! > Maybe a good solution here would be to try and process the tables in the > opposite order when recreating object than the order in which we deleted > them? In which case we (possibly) wouldn't even need a new separate > pass. But I didn't look further into this. What do you think? This was my original idea. I kind of discarded it originally because the two pass approach seemed easier to implement with the current logic, and I didn't want to mess up too much with the code to minimize potential side effects. But I forgot that multi-level partitions were a thing, so we might need to go back and revisit that. It definitely looked like a valid approach too. I'll see if I can come up with something. > I forgot to mention: the patch doesn't apply using git am and needs a > rebase (I applied it using patch -p1 after editing the diff). If you're > still interested in working on this, please provide a rebased patch, as > it makes the process smoother :) Yup! I was aware of that but forgot to update the thread, please find the rebased versions attached. Thanks! Álvaro
v3-0001-Add-regression-test-to-highlight-unexpected-behav.patch
Description: Binary data
v3-0003-Skip-index-rewriting-for-PK-associated-indexes-wh.patch
Description: Binary data
v3-0002-Skip-index-rewriting-when-possible-on-ALTER-TABLE.patch
Description: Binary data
