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;