Commit 663453d5 authored by kaa@mbp.local's avatar kaa@mbp.local

Fix for bug #25162: Backing up DB from 5.1 adds 'USING BTREE' to KEYs

                    on table creates

The problem was in incompatible syntax for key definition in CREATE
TABLE.

5.0 supports only the following syntax for key definition (see "CREATE
TABLE syntax" in the manual):

{INDEX|KEY} [index_name] [index_type] (index_col_name,...)

While 5.1 parser supports the above syntax, the "preferred" syntax was
changed to:

{INDEX|KEY} [index_name] (index_col_name,...) [index_type]

The above syntax is used in 5.1 for the SHOW CREATE TABLE output, which
led to dumps generated by 5.1 being incompatible with 5.0.

Fixed by changing the parser in 5.0 to support both 5.0 and 5.1 syntax
for key definition.
parent 6619db58
......@@ -1532,4 +1532,18 @@ Handler_read_prev 0
Handler_read_rnd 0
Handler_read_rnd_next 7
drop table t1,t2;
CREATE TABLE t1(c1 VARCHAR(33), KEY USING BTREE (c1));
DROP TABLE t1;
CREATE TABLE t1(c1 VARCHAR(33), KEY (c1) USING BTREE);
DROP TABLE t1;
CREATE TABLE t1(c1 VARCHAR(33), KEY USING BTREE (c1) USING HASH) ENGINE=MEMORY;
SHOW INDEX FROM t1;
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment
t1 1 c1 1 c1 NULL 0 NULL NULL YES HASH
DROP TABLE t1;
CREATE TABLE t1(c1 VARCHAR(33), KEY USING HASH (c1) USING BTREE) ENGINE=MEMORY;
SHOW INDEX FROM t1;
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment
t1 1 c1 1 c1 A NULL NULL NULL YES BTREE
DROP TABLE t1;
End of 5.0 tests
......@@ -1148,4 +1148,28 @@ create table t2 select sql_big_result f1,count(f2) from t1 group by f1;
show status like 'handler_read%';
drop table t1,t2;
#
# Bug #25162: Backing up DB from 5.1 adds 'USING BTREE' to KEYs on table creates
#
# Show that the old syntax for index type is supported
CREATE TABLE t1(c1 VARCHAR(33), KEY USING BTREE (c1));
DROP TABLE t1;
# Show that the new syntax for index type is supported
CREATE TABLE t1(c1 VARCHAR(33), KEY (c1) USING BTREE);
DROP TABLE t1;
# Show that in case of multiple index type definitions, the last one takes
# precedence
CREATE TABLE t1(c1 VARCHAR(33), KEY USING BTREE (c1) USING HASH) ENGINE=MEMORY;
SHOW INDEX FROM t1;
DROP TABLE t1;
CREATE TABLE t1(c1 VARCHAR(33), KEY USING HASH (c1) USING BTREE) ENGINE=MEMORY;
SHOW INDEX FROM t1;
DROP TABLE t1;
--echo End of 5.0 tests
......@@ -2982,15 +2982,15 @@ column_def:
;
key_def:
key_type opt_ident key_alg '(' key_list ')'
key_type opt_ident key_alg '(' key_list ')' key_alg
{
LEX *lex=Lex;
Key *key= new Key($1, $2, $3, 0, lex->col_list);
Key *key= new Key($1, $2, $7 ? $7 : $3, 0, lex->col_list);
lex->alter_info.key_list.push_back(key);
lex->col_list.empty(); /* Alloced by sql_alloc */
}
| opt_constraint constraint_key_type opt_ident key_alg '(' key_list ')'
| opt_constraint constraint_key_type opt_ident key_alg '(' key_list ')' key_alg
{
LEX *lex=Lex;
const char *key_name= $3 ? $3:$1;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment