Native Support for BOOLEAN, UUID, and SQL ARRAY Data Types in MySQL

[ScottStroz]

Originally submitted by Øystein Grøvlen of Oracle

Abstract:

This proposal explores adding first-class native support for commonly requested data types such as BOOLEAN, UUID, and SQL-standard ARRAY types in MySQL. The goal is to improve standards compliance, simplify application development, provide clearer metadata semantics, and reduce reliance on workarounds based on aliases, functions, JSON, or application conventions.

Short Description of the Feature:

Introduce native implementations of BOOLEAN, UUID, and potentially SQL ARRAY data types with standardized behavior, metadata support, validation, storage optimization, indexing, replication semantics, and improved interoperability with connectors and developer tools.

Bug DB Link

https://bugs.mysql.com/bug.php?id=120450

Full 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.

Proposal

datatypes-may26.pdf