stored function invoked from different connections".

Invocation of trigger which was using stored function from different
connections caused server crashes (for non-debug server this happened
in highly concurrent environment, but debug server failed on assertion
in relatively simple scenario).

Item_func_sp was not safe to use in triggers (in other words for
re-execution from different threads) as artificial TABLE object
pointed by Item_func_sp::dummy_table referenced incorrect THD
object. To fix the problem we force re-initialization of this
object for each re-execution of statement.

into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge

into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

  bug#21052

into  mockturtle.local:/home/dlenev/src/mysql-5.0-hash-2

Use lazy initialization for Query_tables_list::sroutines hash.
This step should significantly decrease amount of memory consumed
by stored routines as we no longer will allocate chunk of memory
required for this HASH for each statement in routine.

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

  remove timeing dependant part of test

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21915

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug21915

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21915

If the user has specified --max-connections=N or --table-open-cache=M
options to the server, a warning could be given that some values were
recalculated, and table-open-cache could be assigned greater value.

Note that both warning and increase of table-open-cache were totally
harmless.

This patch fixes recalculation code to ensure that table-open-cache will
be never increased automatically and that a warning will be given only if
some values had to be decreased due to operating system limits.

No test case is provided because we neither can't predict nor control
operating system limits for maximal number of open files.

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

into  perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb

into  perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb

into  perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

into  perch.ndb.mysql.com:/home/jonas/src/50-work

  Still leakage, make sure all unlinked operations are put back so they will be release
  (on failing blob operations, when AO_IgnoreError)

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug22584

a updatable view.

When there's a VIEW on a base table that have AUTO_INCREMENT column, and
this VIEW doesn't provide an access such column, after INSERT to such
VIEW LAST_INSERT_ID() did not return the value just generated.

This behaviour is intended and correct, because if the VIEW doesn't list
some columns then these columns are effectively hidden from the user,
and so any side effects of inserting default values to them.

However, there was a bug that such statement inserting into a view would
reset LAST_INSERT_ID() instead of leaving it unchanged.

This patch restores the original value of LAST_INSERT_ID() instead of
resetting it to zero.

into  orca.ndb.mysql.com:/export/home/space/pekka/ndb/version/my50-ndb

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug18819

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819

If the error happens during DELETE IGNORE, nothing could be send to the
client, thus leaving it frozen expecting the reply.

The problem was that if some error occurred, it wouldn't be reported to
the client because of IGNORE, but neither success would be reported.

MySQL 4.1 would not freeze the client, but will report

  ERROR 1105 (HY000): Unknown error

instead, which is also a bug.

The solution is to report success if we are in DELETE IGNORE and some
non-fatal error has happened.

into  mysql.com:/windows/Linux_space/MySQL/mysql-4.1-ndb

into  mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb

into  mysql.com:/windows/Linux_space/MySQL/mysql-5.0

into  mysql.com:/windows/Linux_space/MySQL/mysql-4.1-ndb

Bug #21072  Duplicate key error in NDB references wrong key: Re-wrote string usage to avoid valgrind warnings

into  ymer.(none):/usr/local/mysql/mysql-4.1-ndb

into  ymer.(none):/usr/local/mysql/mysql-5.0-ndb