[pb problem]: ha_heap->clone() fails on windows because of mess with

'/' and '\' in path delimiters:
- Fix this by creating new handler with exactly the same path line as
  was passed to ha_create/ha_open.

sql/ha_heap.cc

@@ -114,6 +114,26 @@ int ha_heap::close(void)
 }
 
 
+/*
+  Create a copy of this table
+
+  DESCRIPTION
+    Do same as default implementation but use file->s->name instead of 
+    table->s->path. This is needed by Windows where the clone() call sees
+    '/'-delimited path in table->s->path, while ha_peap::open() was called 
+    with '\'-delimited path.
+*/
+
+handler *ha_heap::clone(MEM_ROOT *mem_root)
+{
+  handler *new_handler= get_new_handler(table, mem_root, table->s->db_type);
+  if (new_handler && !new_handler->ha_open(file->s->name, table->db_stat,
+                                           HA_OPEN_IGNORE_IF_LOCKED))
+    return new_handler;
+  return NULL;
+}
+
+
 /*
   Compute which keys to use for scanning
 

sql/ha_heap.h

@@ -32,6 +32,7 @@ class ha_heap: public handler
 public:
   ha_heap(TABLE *table);
   ~ha_heap() {}
+  handler *clone(MEM_ROOT *mem_root);
   const char *table_type() const
   {
     return (table->in_use->variables.sql_mode & MODE_MYSQL323) ?

sql/opt_range.cc

@@ -1131,6 +1131,14 @@ int QUICK_RANGE_SELECT::init_ror_merged_scan(bool reuse_handler)
   THD *thd= current_thd;
   if (!(file= head->file->clone(thd->mem_root)))
   {
+    /* 
+      Manually set the error flag. Note: there seems to be quite a few
+      places where a failure could cause the server to "hang" the client by
+      sending no response to a query. ATM those are not real errors because 
+      the storage engine calls in question happen to never fail with the 
+      existing storage engines. 
+    */
+    thd->net.report_error= 1;
     /* Caller will free the memory */
     goto failure;
   }