Test case cleanup.

Actually there is two different bugs.
The first one caused crash on queries with WHERE condition over views
containing WHERE condition. A wrong check for prepared statement phase led
to items for view fields being allocated in the execution memory and freed
at the end of execution. Thus the optimized WHERE condition refers to
unallocated memory on the second execution and server crashed.
The second one caused by the Item_cond::compile function not saving changes
it made to the item tree. Thus on the next execution changes weren't
reverted and server crashed on dereferencing of unallocated space.

The new helper function called is_stmt_prepare_or_first_stmt_execute
is added to the Query_arena class.
The find_field_in_view function now uses
is_stmt_prepare_or_first_stmt_execute() to check whether
newly created view items should be freed at the end of the query execution.
The Item_cond::compile function now saves changes it makes to item tree.

The bug 38816 changed the lock that protects THD::query from
LOCK_thread_count to LOCK_thd_data, but didn't update the associated
InnoDB functions.

1. The innobase_mysql_prepare_print_arbitrary_thd and the
innobase_mysql_end_print_arbitrary_thd InnoDB functions have been
removed, since now we have a per-thread mutex: now we don't need to wrap
several inter-thread access tries to THD::query with a single global
LOCK_thread_count lock, so we can simplify the code.

2. The innobase_mysql_print_thd function has been modified to lock
LOCK_thd_data in direct way.

dependent on the case mode

  is mixed case

Transcode the procedure name to lowercase when searching for it in the 
hash. This is the missing part of the fix for bug #41049.

BUG#46000 - using index called GEN_CLUST_INDEX crashes server

Detailed revision comments:

r6180 | jyang | 2009-11-17 10:54:57 +0200 (Tue, 17 Nov 2009) | 7 lines
branches/5.0: Merge/Port fix for bug #46000 from branches/5.1
-r5895 to branches/5.0. Disallow creating index with the
name of "GEN_CLUST_INDEX" which is reserved for the default
system primary index. Minor adjusts on table name screening
format for added tests.

BUG#47777 - innodb dies with spatial pk: Failing assertion: buf <= original_buf + buf_len

Detailed revision comments:

r6178 | jyang | 2009-11-17 08:52:11 +0200 (Tue, 17 Nov 2009) | 6 lines
branches/5.0: Merge fix for bug #47777 from branches/5.1 -r6045
to bracnches/5.0. Treat the Geometry data same as Binary BLOB
in ha_innobase::store_key_val_for_row(), since the Geometry
data is stored as Binary BLOB in Innodb.

Fixed 2 errors in comp_err executable : 
1. Wrong (off by 1) length passed to my_checksum()
2. strmov() was used on overlapping strings. This is
 not legal according to the docs in stpcpy(). Used 
the overlap safe memmove() instead.

            WHERE conditions 
 
check_group_min_max() checks if the loose index scan 
optimization is applicable for a given WHERE condition, that is 
if the MIN/MAX attribute participates only in range predicates 
comparing the corresponding field with constants. 
 
The problem was that it considered the whole predicate suitable 
for the loose index scan optimization as soon as it encountered 
a constant as a predicate argument. This is obviously wrong for 
cases when a constant is the first argument of a predicate 
which does not satisfy the above condition. 
 
Fixed check_group_min_max() so that all arguments of the input 
predicate are considered to decide if it passes the test, even 
though a constant has already been encountered.

  memory

The server was doing a bad class typecast causing setting of 
wrong value for the maximum number of items in an internal
structure used in equality propagation.
Fixed by not doing the wrong typecast and asserting the type
of the Item where it should be done.

 values
 
 We should re-set the access method functions when changing the access
 method when switching to another index to avoid sorting.
 
 Fixed by doing a little re-engineering : encapsulating all the function
 assignment into a special function and calling it when flipping the 
 indexes.

            only const tables

The problem was caused by two shortcuts in the optimizer that
are inapplicable in the ROLLUP case.

Normally in a case when only const tables are involved in a
query, DISTINCT clause can be safely optimized away since there
may be only one row produced by the join. Similarly, we don't
need to create a temporary table to resolve DISTINCT/GROUP
BY/ORDER BY. Both of these are inapplicable when the WITH
ROLLUP modifier is present.

Fixed by disabling the said optimizations for the WITH ROLLUP
case.

Just change mysql_foo to mysql_cv_foo for one cache-id variable name.  There
was only one bad variable name, present in 5.0 and 5.1, but not in the -pe
branch.

  special chars

This script failed when the user tried passwords with multiple spaces, \, # or
' characters.  Now proper escaping and quoting is used in all contexts.

This problem occurs in the Perl version of this script, too, so fix it in both
places.

Remove a bash-ism (if ! ...).

Bug#41756 "Strange error messages about locks from InnoDB".

In JT_EQ_REF (join_read_key()) access method,
don't try to unlock rows in the handler, unless certain that
a) they were locked
b) they are not used.

Unlocking of rows is done by the logic of the nested join loop,
and is unaware of the possible caching that the access method may
have. This could lead to double unlocking, when a row
was unlocked first after reading into the cache, and then
when taken from cache, as well as to unlocking of rows which
were actually used (but taken from cache).

Delegate part of the unlocking logic to the access method,
and in JT_EQ_REF count how many times a record was actually
used in the join. Unlock it only if it's usage count is 0.

Implemented review comments.

When a sessione is closed, all temporary tables of the session are automatically 
dropped and are binlogged. But it will be binlogged with wrong database names when
the length of the temporary tables' database names are greater than the 
length of the current database name or the current database is not set.

Query_log_event's db_len is forgot to set when Query_log_event's db is set.
This patch wrote code to set db_len immediately after db has set.

Backport a ndb patch: fix bug with crash during restart, where
a mbyte incorrectly could be skipped, leading to "end of log
wo/ finding gci".

Term::ReadKey"

Add the missing module import.  Also, while here, fix a few glaring problems
with the script, and ensure that it behaves properly.  It seems this script
may have never been working correctly (e.g., reading password didn't chomp()
the result, so password was set with \n at the end; comparing the re-typed
password to original was done with inverted test).

Add END { cleanup(); } block to ensure the script removes temporary working
files.

Add SIG{INT} / SIG{QUIT} handler.

Do a bit of reorganization to make the code easier to understand.

Limit failed connection attempts to 3.

Use ./bin/mysql if it exists, and then fall back on mysql in PATH (before it
assumed 'mysql' in the path).  Print a nicer error if 'mysql' can't be called.

This has been tested on Windows (ActivePerl from cmd.exe, no cygwin needed)
and Linux.

            with temporary tables

There were two problems the test case from this bug was
triggering:

1. JOIN::rollup_init() was supposed to wrap all constant Items
into another object for queries with the WITH ROLLUP modifier
to ensure they are never considered as constants and therefore
are written into temporary tables if the optimizer chooses to
employ them for DISTINCT/GROUP BY handling.

However, JOIN::rollup_init() was called before
make_join_statistics(), so Items corresponding to fields in
const tables could not be handled as intended, which was
causing all kinds of problems later in the query execution. In
particular, create_tmp_table() assumed all constant items
except "hidden" ones to be removed earlier by remove_const()
which led to improperly initialized Field objects for the
temporary table being created. This is what was causing crashes
and valgrind errors in storage engines.

2. Even when the above problem had been fixed, the query from
the test case produced incorrect results due to some
DISTINCT/GROUP BY optimizations being performed by the
optimizer that are inapplicable in the WITH ROLLUP case.

Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations
when the WITH ROLLUP modifier is present, and splitting the
const-wrapping part of JOIN::rollup_init() into a separate
method which is now invoked after make_join_statistics() when
the const tables are already known.