BUG#26138 - REPAIR TABLE with option USE_FRM erases all records in

            ARCHIVE table
ARCHIVE table was truncated by REPAIR TABLE ... USE_FRM statement.
The table handler returned its file name extensions in a wrong order.
REPAIR TABLE believed it has to use the meta file to create a new table
from it.

With the fixed order, REPAIR TABLE does now use the data file to create
a new table. So REPAIR TABLE ... USE_FRM works well with ARCHIVE engine
now.

This issue affects 5.0 only, since in 5.1 ARCHIVE engine stores meta
information and data in the same file.

mysql-test/r/archive.result

@@ -12355,3 +12355,12 @@ auto	fld1	companynr	fld3	fld4	fld5
 4	011403	37	intercepted	audiology	tinily
 4	011403	37	intercepted	audiology	tinily
 drop table t1, t2, t4;
+create table t1 (i int) engine=archive;
+insert into t1 values (1);
+repair table t1 use_frm;
+Table	Op	Msg_type	Msg_text
+test.t1	repair	status	OK
+select * from t1;
+i
+1
+drop table t1;

mysql-test/t/archive.test

@@ -1364,3 +1364,13 @@ SELECT * from t2;
 
 
 drop table t1, t2, t4;
+
+#
+# BUG#26138 - REPAIR TABLE with option USE_FRM erases all records in ARCHIVE
+#             table
+#
+create table t1 (i int) engine=archive;
+insert into t1 values (1);
+repair table t1 use_frm;
+select * from t1;
+drop table t1;

sql/examples/ha_example.cc

@@ -211,6 +211,12 @@ ha_example::ha_example(TABLE *table_arg)
   If frm_error() is called then we will use this to to find out what file extentions
   exist for the storage engine. This is also used by the default rename_table and
   delete_table method in handler.cc.
+
+  For engines that have two file name extentions (separate meta/index file
+  and data file), the order of elements is relevant. First element of engine
+  file name extentions array should be meta/index file extention. Second
+  element - data file extention. This order is assumed by
+  prepare_for_repair() when REPAIR TABLE ... USE_FRM is issued.
 */
 static const char *ha_example_exts[] = {
   NullS

sql/ha_archive.cc

@@ -503,8 +503,8 @@ int ha_archive::init_archive_writer()
   We just implement one additional file extension.
 */
 static const char *ha_archive_exts[] = {
-  ARZ,
   ARM,
+  ARZ,
   NullS
 };
 

sql/handler.h

@@ -780,6 +780,17 @@ public:
   virtual void free_foreign_key_create_info(char* str) {}
   /* The following can be called without an open handler */
   virtual const char *table_type() const =0;
+  /*
+    If frm_error() is called then we will use this to find out what file
+    extentions exist for the storage engine. This is also used by the default
+    rename_table and delete_table method in handler.cc.
+
+    For engines that have two file name extentions (separate meta/index file
+    and data file), the order of elements is relevant. First element of engine
+    file name extentions array should be meta/index file extention. Second
+    element - data file extention. This order is assumed by
+    prepare_for_repair() when REPAIR TABLE ... USE_FRM is issued.
+  */
   virtual const char **bas_ext() const =0;
   virtual ulong table_flags(void) const =0;
   virtual ulong index_flags(uint idx, uint part, bool all_parts) const =0;

sql/sql_table.cc

@@ -2068,7 +2068,9 @@ static int prepare_for_repair(THD* thd, TABLE_LIST *table_list,
 
   /*
     Check if this is a table type that stores index and data separately,
-    like ISAM or MyISAM
+    like ISAM or MyISAM. We assume fixed order of engine file name
+    extentions array. First element of engine file name extentions array
+    is meta/index file extention. Second element - data file extention. 
   */
   if (!ext[0] || !ext[1])
     goto end;					// No data file