[MDEV-31191] mysqldump bad format when using CHECK and COMMENT Created: 2023-05-04  Updated: 2023-05-05  Resolved: 2023-05-05

Status: Closed
Project: MariaDB Server
Component/s: Admin statements, Scripts & Clients
Affects Version/s: 10.3.35
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Martín Alfano Assignee: Daniel Black
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Linux


Issue Links:
Duplicate
duplicates MDEV-17654 Incorrect syntax returned for column ... Closed

 Description   

If the table has a CHECK and a COMMENT and mysqldump is used with this table, then the output will be like:

...
`fieldname2` int(10) unsigned NOT NULL DEFAULT 0 ,
`fieldname` int(10) unsigned NOT NULL DEFAULT 0 CHECK (`fieldname` <> 0 or `fieldname2` <> 0) COMMENT 'lala',
...

But when trying to import that, this error is shown:

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'COMMENT 'lala',

If the order is changed manually, this is, COMMENT first and then CHECK, it works.



 Comments   
Comment by Daniel Black [ 2023-05-05 ]

 
MariaDB [test]> select version();
+-----------------+
| version()       |
+-----------------+
| 10.3.39-MariaDB |
+-----------------+
1 row in set (0.000 sec)
 
MariaDB [test]> create table t ( `fieldname2` int(10) unsigned NOT NULL DEFAULT 0 , `fieldname` int(10) unsigned NOT NULL DEFAULT 0 comment 'lalal' CHECK (`fieldname` <> 0 or `fieldname2` <> 0)  );
Query OK, 0 rows affected (0.002 sec)
 
 
MariaDB [test]> show create table t\G
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE `t` (
  `fieldname2` int(10) unsigned NOT NULL DEFAULT 0,
  `fieldname` int(10) unsigned NOT NULL DEFAULT 0 COMMENT 'lalal' CHECK (`fieldname` <> 0 or `fieldname2` <> 0)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci
1 row in set (0.000 sec)

mysqldump just uses show create table. This appears to be fixed in at least the 10.3 instance about to be released.

https://dbfiddle.uk/jhbJ8KGC - 10.3.36 has this fixed.

Generated at Thu Feb 08 10:21:58 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.