Bug #49734: Crash on EXPLAIN EXTENDED UNION ... ORDER BY <any non-const-function>

Several problems fixed : 
1. Non constant expressions in UNION ... ORDER BY were not correctly cleaned up
in st_select_lex_unit::cleanup() causing crashes in EXPLAIN EXTENDED because of
fields quoted by these expressions pointing to the already freed temporary table
used to calculate the UNION.
Fixed by correctly cleaning up expressions of any depth.

2. Subqueries in the order by part of UNION ... ORDER BY ... caused a crash in 
EXPLAIN EXTENDED because of a transformation attempt made during EXPLAIN EXTENDED
execution. Fixed by not doing the transformation when in EXPLAIN.

3. Fulltext functions caused crash when in the ORDER BY part of an un-parenthesized
UNION that gets "promoted" to be valid for the whole union, e.g. 
SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY MATCHES (a) AGAINST ('abc' IN BOOLEAN MODE).
This is a case that demonstrates a more general problem of parts of the query being
moved to another level. When doing such transformation late in the optimization run
when most of the flags about the contents of the query are already aggregated it's possible 
to "split" the flags so that they correctly reflect the new queries after the transformation.
In specific the ST_SELECT_LEX::ftfunc_list is holding all the free text function for all the 
parts of the second SELECT in the UNION and we don't know what part of that is in the ORDER BY
that we're to move to the UNION level and what part is about the other parts of the second SELECT.
Fixed by throwing and error when such statements are about to be processed by adding a check 
for the presence of MATCH() inside the ORDER BY clause that's going to get promoted to UNION.
To workaround this new limitation one must parenthesize the UNION SELECTs and provide a real 
global ORDER BY for the UNION outside of the parenthesis.

4 files changed, 53 insertions, 2 deletions

diff --git a/sql/item.h b/sql/item.h
index b97808ac87f..8f0e5874f3f 100644
--- a/sql/item.h
+++ b/sql/item.h
@@ -967,6 +967,23 @@ public:
     return FALSE;
   }
 
+  /**
+    Find a function of a given type
+
+    @param   arg     the function type to search (enum Item_func::Functype)
+    @return
+      @retval TRUE   the function type we're searching for is found
+      @retval FALSE  the function type wasn't found
+
+    @description
+      This function can be used (together with Item::walk()) to find functions
+      in an item tree fragment.
+  */
+  virtual bool find_function_processor (uchar *arg)
+  {
+    return FALSE;
+  }
+
   /*
     For SP local variable returns pointer to Item representing its
     current value and pointer to current Item otherwise.
diff --git a/sql/item_func.h b/sql/item_func.h
index 259316b0c41..71168c64e4b 100644
--- a/sql/item_func.h
+++ b/sql/item_func.h
@@ -212,6 +212,11 @@ public:
   {
     return has_timestamp_args();
   }
+
+  virtual bool find_function_processor (uchar *arg)
+  {
+    return functype() == *(Functype *) arg;
+  }
 };
 
 
diff --git a/sql/sql_select.cc b/sql/sql_select.cc
index 6383fe63012..d50bb888850 100644
--- a/sql/sql_select.cc
+++ b/sql/sql_select.cc
@@ -519,7 +519,7 @@ JOIN::prepare(Item ***rref_pointer_array,
     thd->lex->allow_sum_func= save_allow_sum_func;
   }
 
-  if (!thd->lex->view_prepare_mode)
+  if (!thd->lex->view_prepare_mode && !(select_options & SELECT_DESCRIBE))
   {
     Item_subselect *subselect;
     /* Is it subselect? */
diff --git a/sql/sql_union.cc b/sql/sql_union.cc
index cbf94ad7181..1760670f9c8 100644
--- a/sql/sql_union.cc
+++ b/sql/sql_union.cc
@@ -335,6 +335,35 @@ bool st_select_lex_unit::prepare(THD *thd_arg, select_result *sel_result,
       }
     }
     
+    /*
+      Disable the usage of fulltext searches in the last union branch.
+      This is a temporary 5.x limitation because of the way the fulltext
+      search functions are handled by the optimizer.
+      This is manifestation of the more general problems of "taking away"
+      parts of a SELECT statement post-fix_fields(). This is generally not
+      doable since various flags are collected in various places (e.g. 
+      SELECT_LEX) that carry information about the presence of certain 
+      expressions or constructs in the parts of the query.
+      When part of the query is taken away it's not clear how to "divide" 
+      the meaning of these accumulated flags and what to carry over to the
+      recipient query (SELECT_LEX).
+    */
+    if (global_parameters->ftfunc_list->elements && 
+        global_parameters->order_list.elements &&
+        global_parameters != fake_select_lex)
+    {
+      ORDER *ord;
+      Item_func::Functype ft=  Item_func::FT_FUNC;
+      for (ord= (ORDER*)global_parameters->order_list.first; ord; ord= ord->next)
+        if ((*ord->item)->walk (&Item::find_function_processor, FALSE, 
+                                (uchar *) &ft))
+        {
+          my_error (ER_CANT_USE_OPTION_HERE, MYF(0), "MATCH()");
+          goto err;
+        }
+    }
+
+
     create_options= (first_sl->options | thd_arg->options |
                      TMP_TABLE_ALL_COLUMNS);
     /*
@@ -669,7 +698,7 @@ bool st_select_lex_unit::cleanup()
     {
       ORDER *ord;
       for (ord= (ORDER*)global_parameters->order_list.first; ord; ord= ord->next)
-        (*ord->item)->cleanup();
+        (*ord->item)->walk (&Item::cleanup_processor, 0, 0);
     }
   }