Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3, 13.1, 13.0.1, 13.1.1
-
None
-
ubuntu 22.04
-
Unexpected results
Description
Hi, MariaDB developer. I find a bug.
When adding a JSON NOT NULL column to a non-empty table, MariaDB completes the ALTER TABLE successfully but initializes existing rows with an empty string.
Since MariaDB represents JSON as LONGTEXT with an automatically generated CHECK (json_valid(column)) constraint, the resulting row immediately violates the table's own constraint.
Step to Rproduce
DROP TABLE IF EXISTS t0; |
CREATE TABLE t0 (c0 INT, PRIMARY KEY (c0)); |
INSERT INTO t0 (c0) VALUES (1); |
ALTER TABLE t0 ADD COLUMN c1 JSON NOT NULL; |
|
|
SHOW CREATE TABLE t0; |
-- c1 longtext NOT NULL CHECK (json_valid(`c1`))
|
|
|
SELECT CONSTRAINT_NAME, CHECK_CLAUSE |
FROM information_schema.CHECK_CONSTRAINTS |
WHERE CONSTRAINT_SCHEMA = DATABASE() AND TABLE_NAME = 't0'; |
-- MariaDB returns: c1 | json_valid(`c1`)
|
|
|
SELECT c0, c1, json_valid(c1) FROM t0; |
-- MariaDB returns: 1 | | 0
|
|
|
SELECT * FROM t0 WHERE (json_valid(c1)) IS FALSE; |
-- MariaDB returns: 1 |
|
-- MySQL returns empty result set |
Expected Behavior
A successful ALTER TABLE should not leave existing rows violating the resulting schema.
MariaDB should either reject the operation or initialize existing rows with a valid JSON value.
Actual Behavior
The operation succeeds, but the existing row gets an empty string, for which:
json_valid(c1) = 0
Therefore, the table contains a row that violates its automatically generated CHECK (json_valid(c1)) constraint immediately after the DDL operation.
Attachments
Issue Links
- relates to
-
MDEV-31008 Instant ALTER allows to violate column check constraint
-
- Confirmed
-