into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge

into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime

test programs.

into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-28318-rework

(this is a backward-compatible change).

into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime

The embedded version of the server doesn't use column level grants, and 
the compile directive NO_EMBEDDED_ACCESS_CHECKS should be checked instead of
the redundant HAVE_QUERY_CACHE (which is always the case) to determine if 
column level grants should be compiled or not.

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)

into  damien-katzs-computer.local:/Users/dkatz/mysql-5.1-runtime

into  damien-katzs-computer.local:/Users/dkatz/mysql-5.0-runtime

explicitly.

of the stored procedure cursors (materialized on disk).

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

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

into  moksha.com.br:/Users/davi/mysql/mysql-5.1-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.

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-27858-b

Before this patch, failures to write to the log tables (mysql.slow_log
and mysql.general_log) were improperly printed (the time was printed twice),
or not printed at all.

With this patch, failures to write to the log tables is reported in the
error log, for all cases of failures.

"DECLARE CURSOR FOR SHOW ..." is a syntax that currently appears to work,
but is untested for some SHOW commands and does not work for other SHOW
commands.

Since this is an un-intended feature that leaked as a result of a coding bug
(in the parser grammar), the correct fix is to fix the grammar to not accept
this construct.

In other words, "DECLARE CURSOR FOR SHOW <other commands that don't work>"
is not considered a bug, and we will not implement other features to make all
the SHOW commands usable inside a cursor just because someone exploited a bug.

mysql_change_user().

The problem was that THD::ull was not reset in THD::cleanup().

The fix is to reset it.

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

static but it's still used by another compilation unit.

Remove static qualifier from do_command definition.

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

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

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

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

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

into  moksha.com.br:/Users/davi/mysql/bugs/21587-5.1

into  damien-katzs-computer.local:/Users/dkatz/mysql-5.1-runtime

into  damien-katzs-computer.local:/Users/dkatz/mysql-5.0-runtime

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.