of SQL_BIG_SELECTS.

The bug was that SQL_BIG_SELECTS was not properly set
in COM_CHANGE_USER.

The fix is to update SQL_BIG_SELECTS properly.

into  station.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

into  moksha.local:/Users/davi/mysql/push/mysql-5.1-runtime

into  station.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

when used in a VIEW.

The problem was that wrong function (create_tmp_from_item())
was used to create a temporary field for Item_func_sp.

The fix is to use create_tmp_from_field().

into  trift2.:/MySQL/M51/push-5.1

into  trift2.:/MySQL/M50/push-5.0

This actually, fix for the patch for bug-27354. The problem with
the patch was that Item_func_sp::used_tables() was updated, but
Item_func_sp::const_item() was not. So, for Item_func_sp, we had
the following inconsistency:
  - used_tables() returned RAND_TABLE, which means that the item
    can produce "random" results;
  - but const_item() returned TRUE, which means that the item is
    a constant one.

The fix is to change Item_func_sp::const_item() behaviour: it must
return TRUE (an item is a constant one) only if a stored function
is deterministic and each of its arguments (if any) is a constant
item.

into  production.mysql.com:/usersnfs/jperkin/bk/build/5.1

into  production.mysql.com:/usersnfs/jperkin/bk/bug-27692/5.0

were accidentally removed during a previous rototill of this
code.  Fixes bug#27692.
  
While it can be argued we should strive to provide a 'secure by
default' installation, this happens to be the setup currently
documented in the manual as the default, so defer changes that
improve security out of the box to a co-ordinated effort later
on.
  
For now, make a note about the test databases and anonymous user
in mysql_install_db and recommend that mysql_secure_installation
be ran for users wishing to remove these defaults.

[..re-commit of previously lost change..]

It's not possible to use WaitForSingleObject to wait
on a CRITICAL_SECTION, instead use the TryEnterCriticalSection function.
 - if "mutex" was already taken => return EBUSY
 - if "mutex" was aquired => return 0

   Updated variable size arrays to use vector like Jonas did for 5.1 so that my build would not break

into  mysql.com:/home/kent/bk/make-install/mysql-5.1-build

  Added special handling of "mysql_install_db" and "mysql.server" scripts,
  find executables relative to the current directory.

into  kindahl-laptop.dnsalias.net:/home/bk/b30992-mysql-5.0-runtime

Adding support for correct handling of pthread_mutex_trylock() on Win32
systems as well as when using the safe mutexes. 

succ. mysql_change_user() call.

Use 2 bytes for character set number.

into  trift2.:/MySQL/M51/push-5.1

into  trift2.:/MySQL/M50/push-5.0

Add the cleanup by dropping the database 'track' in test "rpl_bug31076".

into  trift2.:/MySQL/M51/push-5.1

into  moksha.local:/Users/davi/mysql/push/bugs/21136-regression

caused a few tests to fail because the thd->extra_lock wasn't being set to
NULL after the table was unlocked. This poses a serious problem because later
attempts to access thd->extra_lock (now a dangling pointer) will probably
result in a crash (undefined behavior) -- and that's what actually happens
in some test cases.

The solution is to set the select_create::m_plock pointee to NULL, which
means that thd->extra_lock is set to NULL when the lock data is not for a
temporary table.

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  station.:/mnt/raid/alik/MySQL/devel/bug-30472/5.1-rt-bug30472

the sql_class.h file.

When CREATE TEMPORARY TABLE .. SELECT is invoked from a stored function
which in turn is called from CREATE TABLE SELECT causes a memory leak
because the inner create temporary table overrides the outter extra_lock
reference when locking the table.

The solution is to simply not overrride the extra_lock by only using the
extra_lock for a non-temporary table lock.

insert_id after succ. mysql_change_user() call.

See also WL 4066.
  
This bug reveals two problems:
  - the problem on the client side which was described originally;
  - the problem in protocol / the server side: connection context
    on client and server should be like after mysql_real_connect()
    and be consistent. The server however just resets character
    set variables to the global defaults.

The fix seems to be as follows:
  - extend the protocol so that the client be able to send
    character set information in COM_CHANGE_USER command;
  - change the server so that it understands client character set
    in the command;
  - change the client:
    - reset character set to the default value (which has been
      read from the configuration);
    - send character set in COM_CHANGE_USER command.

into  trift2.:/MySQL/M51/push-5.1

This is mysql-5.1.22-rc.

   Bug #30759  	mysql_install_db fails to set $extra_bindir properly in all cases.