alter table foo_new <insert user’s --alter statement>
copy rows from foo to foo_new
drop foo, rename foo_new to foo
Because you have drop column, rename column in 1 command, the foo_new table only has x column in it because you dropped it, then renamed the _new one. Then when ptosc copies rows from original table, it’s copying rows from x.
The ALTER TABLE is not a two-step process. It is not doing “drop X, copy data, then rename x_new to x” It performs the entire alter first, then copies the data. This behavior you are experiencing is expected.
This won’t solve it. you’ll have the same result because of what I described above.
If x_new already has the data you want, then run ptosc to handle the DROP only. Once done, run a regular alter to rename the column. Renaming a column does not require rebuilding the table (mysql 8.0).
Could you provide the PTDEBUG=1 of your test? I would be interested in seeing what is actually happening when you use CHANGE vs RENAME COLUMN in this case because the resulting column name is the same before the data copy happens.
my $alter_change_col_re = qr/\bCHANGE \s+ (?:COLUMN \s+)?
($table_ident) \s+ ($table_ident)/ix;
pt-osc has a specific check for CHANGE which tracks the old column name and the new name. That’s why it works! This is interesting and something I didn’t know pt-osc did.