ALTER TABLE ignores a changed fulltext parser of an index

On main, an in-place ALTER TABLE that drops a FULLTEXT index of an InnoDB table and adds it again with the same name and columns but another parser does not change anything:

INSTALL PLUGIN simple_parser SONAME 'mypluglib';

CREATE TABLE t (id INT PRIMARY KEY, c TEXT, FULLTEXT ft(c)) ENGINE=InnoDB;

INSERT INTO t VALUES (1, 'abc-def'), (2, 'xyz');

ALTER TABLE t DROP INDEX ft, ADD FULLTEXT ft(c) WITH PARSER simple_parser;

SHOW CREATE TABLE t;

SELECT id FROM t WHERE MATCH(c) AGAINST('abc');

SHOW CREATE TABLE still shows FULLTEXT KEY `ft` (`c`) without the parser, and the SELECT returns 1 because the built-in parser is still used (with simple_parser, 'abc-def' is one word and the SELECT returns nothing). There is no error or warning; even ALGORITHM=INSTANT is accepted. The other way round, ALTER TABLE t DROP INDEX ft, ADD FULLTEXT ft(c) keeps a parser that the index has.

With another index name, ALTER TABLE t DROP INDEX ft, ADD FULLTEXT ft2(c) WITH PARSER simple_parser only renames the index: SHOW CREATE TABLE shows the parser, but the existing rows stay indexed by the built-in parser, so MATCH(c) AGAINST('abc-def') does not find row 1 (a row inserted afterwards is found).

With ALGORITHM=COPY, or with MyISAM (which does this ALTER by copying), the parser is changed. 11.4 rebuilds the index with the new parser in all these cases.

compare_keys_but_name() does not look at the parser (HA_USES_PARSER is not in HA_KEYFLAG_MASK). Before 062f8eb37dd ("cleanup: key algorithm vs key flags", first released in 11.7.1) this did not matter: a FULLTEXT index added by ALTER TABLE had key algorithm HA_KEY_ALG_UNDEF and the existing one HA_KEY_ALG_FULLTEXT, so they never compared equal and the index was always rebuilt. Since that commit both have HA_KEY_ALG_FULLTEXT, so the index compares equal: with the same name nothing is done, with another name it is renamed. 11.8 has that commit.

This matters for MDEV-10267: users who move to the ngram parser may change an existing index this way. MySQL has the same problem (Bug #110976). A fix with a test is ready: compare_keys_but_name() treats an index whose parser is added, removed or replaced as changed.