Adjacent ENUM columns conflate hex-encoded and literal value lists

Creating adjacent ENUM columns whose serialized value lists match, while only one list requires hex encoding, causes the second column to reuse the first column's metadata. This changes its persisted declaration and value semantics. The behavior was reproduced on MariaDB 12.3.3 on Linux/amd64.

Reproducer

Run:

CREATE DATABASE enum_lists;

USE enum_lists;

CREATE TABLE enum_lists (a ENUM('x',0x0061), b ENUM('78','0061')) CHARACTER SET latin1 ENGINE=InnoDB;

SHOW CREATE TABLE enum_lists;

INSERT INTO enum_lists VALUES (2,2);

SELECT HEX(a) AS encoded_value, HEX(b) AS plain_value, HEX(a)='0061' AND HEX(b)='30303631' AS oracle_ok FROM enum_lists;

The client returns:

enum_lists	CREATE TABLE `enum_lists` (

  `a` enum('x','\0a') DEFAULT NULL,

  `b` enum('x','\0a') DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci

0061	0061	0

Both declarations have become enum('x','\0a'), and HEX(b) returns 0061. The two logically distinct value lists should retain separate metadata: after inserting ordinal 2, HEX(a) should return 0061, HEX(b) should return 30303631, and SHOW CREATE TABLE should preserve both declarations.

The isolated second column retains its intended semantics. Remove the first test database, then run the control:

DROP DATABASE IF EXISTS enum_lists;

SELECT COUNT(*)=0 AS cleanup_ok FROM information_schema.schemata WHERE schema_name='enum_lists';

CREATE DATABASE enum_lists;

USE enum_lists;

CREATE TABLE plain_enum (b ENUM('78','0061')) CHARACTER SET latin1 ENGINE=InnoDB;

INSERT INTO plain_enum VALUES(2);

SELECT HEX(b), HEX(b)='30303631' AS oracle_ok FROM plain_enum;

DROP DATABASE enum_lists;

The control returns:

30303631	1

Source inspection of 13.2.0-alpha indicates that get_interval_id() compares serialized TYPELIB strings with strcmp() and distinguishes mbminlen, but not whether a list carries FIELDFLAG_FRM_HEX_ENCODED_TYPELIB. This allows the lists to share an interval even though only one must be decoded from hex notation. The exact 13.2.0-alpha binary was not tested.

This occurs when adjacent ENUM columns have matching serialized value lists but only one list requires hex encoding.