ALTER TABLE...FORCE fails to recalculate generated stored columns

monty pointed out that when there are generated stored columns that might have been miscalculated due to an earlier bug, the statement

ALTER TABLE t FORCE;

would fail to correctly recalculate the generated stored columns. I do not know a specific example of such a bug, but I think that the concern is plausible.

The idea is that we would want the following outcome:

--source include/have_innodb.inc

CREATE TABLE t1 (a INT GENERATED ALWAYS AS (42)) ENGINE=InnoDB;

--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON

ALTER TABLE t1 FORCE, ALGORITHM=INPLACE;

--echo # the following would use ALGORITHM=COPY

ALTER TABLE t1 FORCE;

ALTER TABLE t1 ALGORITHM=COPY;

However, I do not know if this is a good idea. Maybe bugs related to stored generated columns are rare enough that it is enough that the user can explicitly specify ALGORITHM=COPY.

Maybe a better idea would be to introduce a REPAIR option to ALTER TABLE. This option would be mostly like FORCE, but it would instruct InnoDB to refuse a native rebuild in this particular case, as well as in some other column conversions that might not be representable by setting the ALTER_COLUMN_STORAGE_TYPE flag:

--source include/have_innodb.inc

CREATE TABLE t1 (a INT GENERATED ALWAYS AS (42)) ENGINE=InnoDB;

--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON

ALTER TABLE t1 REPAIR, ALGORITHM=INPLACE;

--echo # the following would use ALGORITHM=INPLACE

ALTER TABLE t1 FORCE, ALGORITHM=INPLACE;

ALTER TABLE t1 FORCE;

--echo # the following would use ALGORITHM=COPY

ALTER TABLE t1 REPAIR;

ALTER TABLE t1 ALGORITHM=COPY;