Description:
Explore adding first-class native support for data types that MySQL
users commonly model today through aliases, functions, JSON values, or
storage conventions. The initial candidates are BOOLEAN, UUID, and
possibly SQL-standard ARRAY types.
For BOOLEAN, the main user-visible goal is to move from BOOL/BOOLEAN
as aliases for TINYINT(1) toward a real Boolean type with clear
metadata, dump/restore behavior, replication semantics, and standard
truth values (See WL#3554). A key community discussion point is
compatibility: how and when existing BOOL/BOOLEAN declarations should
change behavior, and what migration path users expect.
For UUID, MySQL already provides useful functions such as UUID(),
UUID_TO_BIN(), BIN_TO_UUID(), and IS_UUID(), but users still have to
choose between CHAR(36), BINARY(16), generated columns, check
constraints, and application conventions. A native UUID type could
provide built-in validation, compact 16-byte storage, canonical
textual input/output, clearer metadata for tools and connectors,
well-defined comparison and index behavior, and a cleaner migration
path from today’s function-based patterns. The main community question
is what remains painful with the current functions, and whether users
need a true type rather than better functions and documentation.
For ARRAY, MySQL already has partial typed-array syntax for
multi-valued indexes, but it is not a general SQL array type. Full
support should be evaluated against the SQL standard, including typed
array columns and expressions, array constructors, element access,
casts, comparison rules, null handling, functions/operators,
UNNEST-style query integration, storage, replication, and
indexing. The community discussion should clarify whether users need
standard SQL arrays, whether JSON arrays are insufficient for their
use cases, and which array operations matter most.
How to repeat:
N/A
© 2026, Oracle Corporation and/or its affiliates