into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-maint

into  example.com:/work/bug22369-v2/my51

into  naruto.:C:/cpp/mysql-5.1-maint

disables binlog.

into  example.com:/work/bug22369-v2/my51

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-5.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

Close any statements that might be open before program exit
Close any statments that might be open when calling "disable_ps_protocol"

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/bug20836/my51-bug20836

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-5.0-maint

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-5.1-maint

into  example.com:/work/bug22369-v2/my51

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/bug17951/my51-bug17951

with other alterations causes lost tables

Using RENAME clause combined with other clauses of ALTER TABLE led to
data loss (the data was there but not accessible). This could happen if the
changes do not change the table much. Adding and droppping of fields and
indices was safe. Renaming a column with MODIFY or CHANGE was unsafe operation,
if the actual column didn't change (changing from int to int, which is a noop)
  
Depending on the storage engine (SE) the behavior is different:
1)MyISAM/MEMORY - the ALTER TABLE statement completes
  without any error but next SELECT against the new table fails.
2)InnoDB (and every other transactional table) - The ALTER TABLE statement
  fails. There are the the following files in the db dir -
  `new_table_name.frm` and a temporary table's frm. If the SE is file
  based, then the data and index files will be present but with the old
  names. What happens is that for InnoDB the table is not renamed in the
  internal DDIC.

Fixed by adding additional call to mysql_rename_table() method, which should
not include FRM file rename, because it has been already done during file
names juggling.

into  dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.1

into  dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.0

 - Add CR_CONN_HOST_ERROR to list of errorcode that trigger another connection
   attempt in mysqltest

into  naruto.:C:/cpp/mysql-5.1-maint

  fixed a valgrind problem

   fixed a valgrind warning
type_varchar.test:
  fixed a valgrind warning

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

  Disabled abi_check, as it was before merge

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

  If --srcdir and --windows is given, check if error message file
  is in source or build tree (bug#24557)
Makefile.am:
  Cleaned up "ali_check" target, to satisfy "distcleancheck" (bug#24557)
mysql_install_db.sh:
  Added --srcdir=DIR option, used from top Makefile.am in dist-hook
  target, to find "fill_help_tables.sql" in VPATH build (bug#24557)
Makefile.am:
  Work around problem with "distcleancheck", "sql_yacc.cc" might be in both
  the source and build tree.
  Call "mysql_install_db" with new option --srcdir, to enable the script
  to find all that is needed, if source and build directory is not the same
  (bug#24557)

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-maint-24736

into  example.com:/work/bug24395-v2/my51

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

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

  Added "mysql_client_test.def"
mysql_client_test.def:
  BitKeeper file /home/kent/bk/mysql-5.0-build/netware/mysql_client_test.def

  Adjusted for storage path
nwbootstrap:
  Corrected bad merge

Before this fix, a call to a User Defined Function (UDF) could,
under some circumstances, be interpreted as a call to a Stored function
instead. This occurred if a native function was invoked in the parameters
for the UDF, as in "select my_udf(abs(x))".

The root cause of this defect is the introduction, by the fix for Bug 21809,
of st_select_lex::udf_list, and it's usage in the parser in sql_yacc.yy
in the rule function_call_generic (in 5.1).

While the fix itself for Bug 21809 is correct in 5.0, the code change
merged into the 5.1 release created the issue, because the calls in 5.1 to :
- lex->current_select->udf_list.push_front(udf)
- lex->current_select->udf_list.pop()
are not balanced in case of native functions, causing the udf_list,
which is really a stack, to be out of sync with the internal stack
maintained by the bison parser.

Instead of moving the call to udf_list.pop(), which would have fixed the
symptom, this patch goes further and removes the need for udf_list.

This is motivated by two reasons:

a) Maintaining a stack in the MySQL code in sync with the stack maintained
internally in sql_yacc.cc (not .yy) is extremely dependent of the
implementation of yacc/bison, and extremely difficult to maintain.
It's also totally dependent of the structure of the grammar, and has a risk
to break with regression defects each time the grammar itself is changed.

b) The previous code did report construct like "foo(expr AS name)" as
syntax errors (ER_PARSER_ERROR), which is incorrect, and misleading.
The syntax is perfectly valid, as this expression is valid when "foo" is
a UDF. Whether this syntax is legal or not depends of the semantic of "foo".

With this change:

a) There is only one stack (in bison), and no List<udf_func> to maintain.

b) "foo(expr AS name)", when used incorrectly, is reported as semantic error:
- ER_WRONG_PARAMETERS_TO_NATIVE_FCT (for native functions)
- ER_WRONG_PARAMETERS_TO_STORED_FCT (for stored functions)
This is achieved by the changes implemented in item_create.cc