mysql-test/r/sp.result:
  Added tests for coverage
mysql-test/t/sp.test:
  Added tests for coverage
sql/sql_udf.cc:
  Code cleanup

The root cause of the issue was that the CREATE FUNCTION grammar,
for User Defined Functions, was using the sp_name rule.
The sp_name rule is intended for fully qualified stored procedure names,
like either ident.ident, or just ident but with a default database
implicitly selected.

A UDF does not have a fully qualified name, only a name (ident), and should
not use the sp_name grammar fragment during parsing.

The fix is to re-organize the CREATE FUNCTION grammar, to better separate:
- creating UDF (no definer, can have AGGREGATE, simple ident)
- creating Stored Functions (definer, no AGGREGATE, fully qualified name)

With the test case provided, another issue was exposed which is also fixed:
the DROP FUNCTION statement was using sp_name and also failing when no database
is implicitly selected, when droping UDF functions.
The fix is also to change the grammar so that DROP FUNCTION works with
both the ident.ident syntax (to drop a stored function), or just the ident
syntax (to drop either a UDF or a Stored Function, in the current database)


mysql-test/r/sp-error.result:
  Adjust test results
mysql-test/r/udf.result:
  Adjust test results
mysql-test/t/sp-error.test:
  Adjust test results
mysql-test/t/udf.test:
  Adjust test results
sql/sql_parse.cc:
  CREATE UDF FUNCTION does not use a fully qualified name.
sql/sql_yacc.yy:
  Fix grammar for CREATE / DROP FUNCTION, FOR udf
  Improve error messages for select no_such_function()

into  moksha.com.br:/Users/davi/mysql/mysql-5.0-runtime

If mysql_lock_tables fails because the lock was aborted, we need to
reset thd->some_tables_delete, otherwise we might loop indefinitely
because handler's tables are not closed in a standard way, meaning
that close_thread_tables() (which resets some_tables_deleted) is not
used.

This patch fixes sporadical failures of handler_myisam/innodb tests
which were introduced by previous fix for this bug.


sql/sql_handler.cc:
  Properly reset thd->some_tables_deleted if mysql_lock_tables
  fails for some reason.

mysql-test/r/sp.result:
  Update result file.

into  virtua-cwbas201-21-158-74.ctb.virtua.com.br:/Users/davi/mysql/push/mysql-5.0-runtime


sql/sql_yacc.yy:
  Auto merged

Bug#29816 Syntactically wrong query fails with misleading error message

The core problem is that an SQL-invoked function name can be a <schema
qualified routine name> that contains no <schema name>, but the mysql
parser insists that all stored procedures (function, procedures and
triggers) must have a <schema name>, which is not true for functions.
This problem is especially visible when trying to create a function
or when a query contains a syntax error after a function call (in the
same query), both will fail with a "No database selected" message if
the session is not attached to a particular schema, but the first
one should succeed and the second fail with a "syntax error" message.

Part of the fix is to revamp the sp name handling so that a schema
name may be omitted for functions -- this means that the internal
function name representation may not have a dot, which represents
that the function doesn't have a schema name. The other part is
to place schema checks after the type (function, trigger or procedure)
of the routine is known.


mysql-test/r/sp-error.result:
  Add test case result for Bug#29816
mysql-test/r/udf.result:
  Add test case result for Bug#28318
mysql-test/t/sp-error.test:
  Add test case for Bug#29816
mysql-test/t/udf.test:
  Add test case for Bug#28318
sql/sp.cc:
  Copy the (last) nul byte of the stored routine key and move name parsing
  code to the sp_name class constructor.
sql/sp_head.cc:
  Revamp routine name parsing for when no schema is specified and
  omit dot from the qualified name if the routine is not associated
  with a scheme name.
sql/sp_head.h:
  Name parsing got bigger, uninline by moving to a single unit -- the sp_head.cc
  file.
sql/sql_yacc.yy:
  Only copy the schema name if one is actually set and check for schema
  name presence only where it's necessary.

into  moksha.com.br:/Users/davi/mysql/push/bugs/31409-5.0

This deadlock occurs when a client issues a HANDLER ... OPEN statement
that tries to open a table that has a pending name-lock on it by another
client that also needs a name-lock on some other table which is already
open and associated to a HANDLER instance owned by the first client.
The deadlock happens because the open_table() function will back-off
and wait until the name-lock goes away, causing a circular wait if some
other name-lock is also pending for one of the open HANDLER tables.

Such situation, for example, can be easily repeated by issuing a RENAME
TABLE command in such a way that the existing table is already open
as a HANDLER table by another client and this client tries to open
a HANDLER to the new table name.

The solution is to allow handler tables with older versions (marked for
flush) to be closed before waiting for the name-lock completion. This is
safe because no other name-lock can be issued between the flush and the
check for pending name-locks.

The test case for this bug is going to be committed into 5.1 because it
requires a test feature only avaiable in 5.1 (wait_condition).


sql/sql_base.cc:
  Improve comments in the open_table() function, stating the importance
  of the handler tables flushing for the back-off process.
sql/sql_handler.cc:
  Allows handler tables flushes when opening new tables in order to avoid
  potential deadlocks. Add comments explaining the importance of the flush.

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


mysql-test/r/sp.result:
  Auto merged
mysql-test/t/sp.test:
  Auto merged
sql/sql_parse.cc:
  Auto merged

into  pilot.mysql.com:/data/msvensson/mysql/my50-r-bug30992

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

This bug is a symptom of the way handler's tables are managed. The
most different aspect, compared to the conventional behavior, is that
the handler's tables are long lived, meaning that their lifetimes are
not bounded by the duration of the command that opened them. For this
effect the handler code uses its own list (handler_tables instead of
open_tables) to hold open handler tables so that the tables won't be
closed at the end of the command/statement. Besides the handler_tables
list, there is a hash (handler_tables_hash) which is used to associate
handler aliases to tables and to refresh the tables upon demand (flush
tables).

The current implementation doesn't work properly with refreshed tables
-- more precisely when flush commands are issued by other initiators.
This happens because when a handler open or read statement is being
processed, the associated table has to be opened or locked and, for this
matter, the open_tables and handler_tables lists are swapped so that the
new table being opened is inserted into the handler_tables list. But when
opening or locking the table, if the refresh version is different from the
thread refresh version then all used tables in the open_tables list (now
handler_tables) are refreshed. In the "refreshing" process the handler
tables are flushed (closed) without being properly unlinked from the
handler hash.

The current implementation also fails to properly discard handlers of
dropped tables, but this and other problems are going to be addressed
in the fixes for bugs 31397 and 31409.

The chosen approach tries to properly save and restore the table state
so that no table is flushed during the table open and lock operations.
The logic is almost the same as before with the list swapping, but with
a working glue code.

The test case for this bug is going to be committed into 5.1 because it
requires a test feature only avaiable in 5.1 (wait_condition).


sql/sql_handler.cc:
  Backup and reset the open_tables and handler_table lists when opening
  a new handler table and merge the opened table into the handler_tables
  list afterwards. When locking, do the same but possibly close the table
  if a refresh is pending.

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.


mysql-test/r/sp.result:
  Update result file.
mysql-test/t/sp.test:
  Add test cases for BUG-31035, BUG-31191, BUG-31226
sql/item_func.cc:
  Make Item::const_item() be consistent with Item::used_tables().

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..]


scripts/mysql_system_tables_data.sql:
  Add anonymous accounts.
scripts/mysql_install_db.sh:
  Point users at the mysql_secure_installation script.
mysql-test/mysql-test-run.pl:
  Add a comment where removing anonymous users.

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


include/config-win.h:
  Make windows.h define TryEnterCriticalSection
mysys/my_winthread.c:
  Use the TryEnterCriticalSection function to implement pthread_mutex_trylock
  Prevent recursive behaviour by looking at the RecursionCount variable
  in the CRITICAL_SECTION struct and return EBUSY from function if
  the mutex was already locked once.

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


ndb/test/ndbapi/testScanFilter.cpp:
   Updated variable size arrays to use vector like Jonas did for 5.1 so that my build would not break

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


include/my_pthread.h:
  Auto merged

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


include/my_pthread.h:
  Adding win_pthread_mutex_trylock() function as wrapper function for
  Windows implementation of pthread_mutex_trylock().
  
  Adding flag to safe_mutex_lock() that is shall not abort if the mutex
  is already locked and instead return EBUSY since this is the POSIX
  behaviour.
mysys/my_winthread.c:
  Added Win32 wrappper function to handle pthread_mutex_trylock().
mysys/thr_mutex.c:
  Added parameter 'try_lock' to safe_mutex_lock() to allow it to do double-
  duty as a pthread_mutex_trylock() in addition to working as
  pthread_mutex_lock().
  
  The code needs to return EBUSY instead of throwing an error in the event
  that the mutex is re-locked (we do not have recursive mutexes), but it
  also requires some special handling to avoid race conditions when
  calling the real pthread_mutex_{lock,trylock}().

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

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

mysys/mf_tempfile.c:
  Try to avoid passing null as first parameter to GetTempFileName, since it's documented that it won't work.

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

cmake list are auto-generated and thus still required.  Correct fix
not yet known.


bdb/CMakeLists.txt:
  Revert previous change, it is incorrect as those files are automatically
  generated.

added get_field_default_value() function which obtains default value from the field
(used in store_create_info() & get_schema_column_record() functions)


mysql-test/r/alter_table.result:
  result fix
mysql-test/r/create.result:
  result fix
mysql-test/r/ctype_collate.result:
  result fix
mysql-test/r/ctype_recoding.result:
  result fix
mysql-test/r/default.result:
  result fix
mysql-test/r/gis.result:
  result fix
mysql-test/r/grant.result:
  result fix
mysql-test/r/information_schema.result:
  result fix
mysql-test/r/key.result:
  result fix
mysql-test/r/mysql.result:
  result fix
mysql-test/r/ps_1general.result:
  result fix
mysql-test/r/show_check.result:
  result fix
mysql-test/r/sp.result:
  result fix
mysql-test/r/type_enum.result:
  result fix
mysql-test/r/type_ranges.result:
  result fix
mysql-test/t/information_schema.test:
  test case

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

  Post-fix for bug#27695.


mysql-test/t/select.test:
  Post-fix for bug#27695.

into  devsrv-b.mysql.com:/data0/gshchepa/mysql-5.0-opt

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

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

into  trift2.:/MySQL/M41/push-4.1

into  magare.gmz:/home/kgeorge/mysql/autopush/B31001-5.0-opt

The optimizer sets index traversal in reverse order only if there are 
 used key parts that are not compared to a constant.
However using the primary key as an ORDER BY suffix rendered the check
incomplete : going in reverse order must still be used even if 
all the parts of the secondary key are compared to a constant.

Fixed by relaxing the check and set reverse traversal even when all
the secondary index keyparts are compared to a const.
Also account for the case when all the primary keys are compared to a
constant.


mysql-test/r/innodb_mysql.result:
  Bug #31001: test case
mysql-test/t/innodb_mysql.test:
  Bug #31001: test case
sql/sql_select.cc:
  Bug #31001: 
   - account for the case when all the primary key parts are compared
     to a constant
   - force test_if_skip_sort_order to go backwards over the key even 
     when the number of keyparts used is the same as the number of 
     keyparts equal to a constant. (because of the primary key 
     suffix).

into  mysql.com:/home/psergey/mysql-5.0-bug30324