or implicitly uses stored function gives "Table not locked" error'

CREATE TABLE ... SELECT ... statement which was explicitly or implicitly
(through view) using stored function gave "Table not locked" error.

The actual bug resides in the current locking scheme of CREATE TABLE SELECT
code, which first opens and locks tables of the SELECT statement itself,
and then, having SELECT tables locked, creates the .FRM, opens the .FRM and
acquires lock on it. This scheme opens a possibility for a deadlock, which
was present and ignored since version 3.23 or earlier. This scheme also
conflicts with the invariant of the prelocking algorithm -- no table can
be open and locked while there are tables locked in prelocked mode.

The patch makes an exception for this invariant when doing CREATE TABLE ...
SELECT, thus extending the possibility of a deadlock to the prelocked mode.
We can't supply a better fix in 5.0.

  Buffer was too small to load Index.xml.
  So some charsets were not gerenrated.
  Making the buffer bigger, and adding an DBUG_ASSERT,
  to easier catch the problem in the future.
ctype-extra.c:
  Additional charsets were generated.

into sunlight.local:/local_work/16281-bug-5.0-mysql

Mutli-table uses temporary table to store new values for fields. With the
new values the rowid of the record to be updated is stored in a Field_string
field. Table to be updated is set as source table of the rowid field.
But when the temporary table creates the tmp field for the rowid field it
converts it to a varstring field because the table to be updated was created by
the v4.1. Due to this the stored rowids were broken and no records for 
update were found.

The flag can_alter_field_type is added to Field_string class. When it is set to
0 the field won't be converted to varstring. The Field_string::type() function 
now always returns MYSQL_TYPE_STRING if can_alter_field_type is set to 0.
The multi_update::initialize_tables() function now sets can_alter_field_type
flag to 0 for the rowid fields denying conversion of the field to a varstring
field.

into  mysql.com:/usr/home/bar/mysql-5.0

into  rurik.mysql.com:/home/igor/mysql-5.0

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0

into  rurik.mysql.com:/home/igor/mysql-5.0

into  mysql.com:/usr/home/bar/mysql-5.0

into  mysql.com:/usr/home/bar/mysql-4.1.12076

  Distribute mysql-test-run.pl

into mysql.com:/Users/kent/mysql/bk/mysql-4.1-new

  Changed web address order.mysql.com to shop.mysql.com

  Install Perl mysql-test-run into test directory

Results changed after the bug fix.

Multiple equalities were not adjusted after reading constant tables.
It resulted in neglecting good index based methods that could be
used to access of other tables.

  Let "make install" install mysql-test-run.pl
mysql.spec.sh:
  Set $LDFLAGS from $MYSQL_BUILD_LDFLAGS (bug#16662)

into mysql.com:/Users/kent/mysql/bk/mysql-4.1-new

  Typo (bug#17167)

  Use CPPFLAGS when testing to link "libz" found in --with-zlib-dir=,
  and search the given include directory first (bug#18369)

into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new

  Use CPPFLAGS when testing to link "libz" found in --with-zlib-dir=,
  and search the given include directory first (bug#18369)

into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new

into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new

into  mysql.com:/home/alexi/innodb/mysql-5.0-merged

  Set MYSQL_SERVER_SUFFIX from build scripts, not hard
  code it into Visual Studio project files, bug#15974

  Enable automake to determine dependency on yaSSL, by explicitly
  listing the .la files in Makefile.am, instead of using
  'yassl_libs_with_path', bug#18273

into  mysql.com:/home/alexi/innodb/mysql-5.0-merged

 Fixed BUG#15650: DELETE with LEFT JOIN crashes server
 with innodb_locks_unsafe_for_binlog.
 Fixed compilation problem with non-C99 compilers
 in btr0sea.c

into  mysql.com:/home/timka/mysql/src/5.0-bug-16710

The bug was due to a missed case in the detection of whether an index
can be used for loose scan. More precisely, the range optimizer chose
to use loose index scan for queries for which the condition(s) over
an index key part could not be pushed to the index together with the
loose scan.

As a result, loose index scan was selecting the first row in the
index with a given GROUP BY prefix, and was applying the WHERE
clause after that, while it should have inspected all rows with
the given prefix, and apply the WHERE clause to all of them.

The fix detects and skips such cases.