Details
-
Bug
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.11, 13.1
Description
In a database whose default character set is not utf8mb4 (e.g. latin1), a JSON_TABLE column with the BINARY attribute has collation <db default>_bin (e.g. latin1_bin) when queried directly; but wrapping the same query in a view changes the column collation to utf8mb4_bin. During view-definition serialization the BINARY attribute is materialized into a hardcoded CHARSET utf8mb4 COLLATE utf8mb4_bin, losing the "follow the database default character set" semantics.
CREATE DATABASE d DEFAULT CHARACTER SET latin1;
|
USE d;
|
SET NAMES latin1;
|
|
|
-- Direct execution: latin1_bin (correct, follows the db default) |
SELECT collation(name) FROM json_table('[{"name":"Jeans"}]', '$[*]' |
COLUMNS(name VARCHAR(10) BINARY PATH '$.name')) AS jt; |
-- => latin1_bin
|
|
|
-- Through a view: drifts to utf8mb4_bin
|
CREATE VIEW v1 AS SELECT * FROM json_table('[{"name":"Jeans"}]', '$[*]' |
COLUMNS(name VARCHAR(10) BINARY PATH '$.name')) AS jt; |
SELECT collation(name) FROM v1;
|
-- => utf8mb4_bin
|
|
|
SHOW CREATE VIEW v1;
|
-- The view definition is rewritten as: name varchar(10) CHARSET utf8mb4 COLLATE utf8mb4_bin |
-- (hardcoded utf8mb4, while direct execution semantics follow the database default latin1) |
|
Attachments
Issue Links
- is caused by
-
MDEV-36764 Unexpected collation when using json_table
-
- Closed
-