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.

1 files changed, 11 insertions, 0 deletions

diff --git a/sql/handler.h b/sql/handler.h
index 9e381ca4482..9863d541b5f 100644
--- a/sql/handler.h
+++ b/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;