Most of this information will be delivered by storage engines via the existing virtual member function handler::check_if_supported_inplace_alter() already.
Accurate information about ROW_FORMAT is returned by SHOW TABLE STATUS; the format used by InnoDB may differ from what is in the .frm file.

As far as I can tell, the only question that the handler API cannot currently answer is whether a table is in the non-canonical format that was introduced by MDEV-11369 (instant ADD COLUMN) and extended in MDEV-15562. Perhaps we should extend SHOW TABLE STATUS with this information, and also let handler::check_if_supported_inplace_alter() assign a flag that informs whether the table would be in non-canonical format after the operation.

Note that an ALGORITHM=NOCOPY operation may convert a table to non-canonical format, even though the complete operation is not ALGORITHM=INSTANT. Also, the table may already be in non-canonical format, and as a result of ALTER, it can either be in canonical or non-canonical format. For example, if the table would be rebuilt due to the FORCE keyword, or due to changing the data type of a column, the table would always be in the canonical format.

The changes to InnoDB should be minimal (doable in a few hours, once the storage engine interface changes have been implemented in a development branch). The bulk of this work should be done outside storage engines.

Hi marko,

Accurate information about ROW_FORMAT is returned by SHOW TABLE STATUS; the format used by InnoDB may differ from what is in the .frm file.

SHOW TABLE STATUS would provide the table's current ROW_FORMAT value. If we support EXPLAIN for ALTER TABLE, then I was thinking that EXPLAIN should ask the storage engine whether the ROW_FORMAT of the table will be changed by the ALTER TABLE. It is not always obvious. For example, some users may not expect the row format of the table to change in the following case, if they were not aware that the value of innodb_default_row_format has been changed, or if they were not aware that the FORCE keyword could cause the ROW_FORMAT to change:

MariaDB [db1]> SET GLOBAL innodb_default_row_format='DYNAMIC';

Query OK, 0 rows affected (0.000 sec)

MariaDB [db1]> CREATE OR REPLACE TABLE tab (id int primary key);

Query OK, 0 rows affected (0.013 sec)

MariaDB [db1]> SELECT NAME, ROW_FORMAT

    -> FROM information_schema.INNODB_SYS_TABLES

    -> WHERE NAME = 'db1/tab';

+---------+------------+

| NAME    | ROW_FORMAT |

+---------+------------+

| db1/tab | Dynamic    |

+---------+------------+

1 row in set (0.000 sec)

MariaDB [db1]> SET GLOBAL innodb_default_row_format='COMPACT';

Query OK, 0 rows affected (0.000 sec)

MariaDB [db1]> ALTER TABLE tab ADD COLUMN c varchar(50), FORCE;

Query OK, 0 rows affected (0.018 sec)

Records: 0  Duplicates: 0  Warnings: 0

MariaDB [db1]> SELECT NAME, ROW_FORMAT

    -> FROM information_schema.INNODB_SYS_TABLES

    -> WHERE NAME = 'db1/tab';

+---------+------------+

| NAME    | ROW_FORMAT |

+---------+------------+

| db1/tab | Compact    |

+---------+------------+

1 row in set (0.000 sec)

Can you please clarify the FixVersion, please?

Hi, sorry to spam you, but please add a fixVersion to those MENT issues.