------------------------------------------------------------
revno: 2597.4.17
revision-id: sp1r-davi@mysql.com/endora.local-20080328174753-24337
parent: sp1r-anozdrin/alik@quad.opbmk-20080328140038-16479
committer: davi@mysql.com/endora.local
timestamp: Fri 2008-03-28 14:47:53 -0300
message:
Bug#15192 "fatal errors" are caught by handlers in stored procedures
The problem is that fatal errors (e.g.: out of memory) were being
caught by stored procedure exception handlers which could cause
the execution to not be stopped due to a continue handler.
The solution is to not call any exception handler if the error is
fatal and send the fatal error to the client.
------------------------------------------------------------
revno: 2572.2.1
revision-id: sp1r-davi@mysql.com/endora.local-20080227225948-16317
parent: sp1r-anozdrin/alik@quad.-20080226165712-10409
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-02-27 19:59:48 -0300
message:
Bug#27525 table not found when using multi-table-deletes with aliases over several databas
Bug#30234 Unexpected behavior using DELETE with AS and USING
The multi-delete statement has a documented limitation that
cross-database multiple-table deletes using aliases are not
supported because it fails to find the tables by alias if it
belongs to a different database. The problem is that when
building the list of tables to delete from, if a database
name is not specified (maybe an alias) it defaults to the
name of the current selected database, making impossible to
to properly resolve tables by alias later. Another problem
is a inconsistency of the multiple table delete syntax that
permits ambiguities in a delete statement (aliases that refer
to multiple different tables or vice-versa).
The first step for a solution and proper implementation of
the cross-databse multiple table delete is to get rid of any
ambiguities in a multiple table statement. Currently, the parser
is accepting multiple table delete statements that have no obvious
meaning, such as:
DELETE a1 FROM db1.t1 AS a1, db2.t2 AS a1;
DELETE a1 AS a1 FROM db1.t1 AS a1, db2.t2 AS a1;
The solution is to resolve the left part of a delete statement
using the right part, if the a table on right has an alias,
it must be referenced in the left using the given alias. Also,
each table on the left side must match unambiguously only one
table in the right side.
------------------------------------------------------------
revno: 2630.39.3
revision-id: davi.arnaut@sun.com-20081210215359-i876m4zgc2d6rzs3
parent: kostja@sun.com-20081208222938-9es7wl61moli71ht
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 36649-6.0
timestamp: Wed 2008-12-10 19:53:59 -0200
message:
Bug#36649: Condition area is not properly cleaned up after stored routine invocation
The problem is that the diagnostics area of a trigger is not
isolated from the area of the statement that caused the trigger
invocation. In MySQL terms, it means that warnings generated
during the execution of the trigger are not removed from the
"warning area" at the end of the execution.
Before this fix, the rules for MySQL message list life cycle (see
manual entry for SHOW WARNINGS) did not apply to statements
inside stored programs:
- The manual says that the list of messages is cleared by a
statement that uses a table (any table). However, such
statement, if run inside a stored program did not clear the
message list.
- The manual says that the list is cleared by a statement that
generates a new error or a warning, but this was not the case
with stored program statements either and is changed to be the
case as well.
In other words, after this fix, a statement has the same effect
on the message list regardless of whether it's executed inside a
stored program/sub-statement or not.
This introduces an incompatible change:
- before this fix, a, e.g. statement inside a trigger could
never clear the global warning list
- after this fix, a trigger that generates a warning or uses a
table, clears the global warning list
- however, when we leave a trigger or a function, the caller's
warning information is restored (see more on this below).
This change is not backward compatible as it is intended to make
MySQL behavior similar to the SQL standard behavior:
A stored function or trigger will get its own "warning area" (or,
in standard terminology, diagnostics area). At the beginning of
the stored function or trigger, all messages from the caller area
will be copied to the area of the trigger. During execution, the
message list will be cleared according to the MySQL rules
described on the manual (SHOW WARNINGS entry). At the end of the
function/trigger, the "warning area" will be destroyed along with
all warnings it contains, except that if the last statement of
the function/trigger generated messages, these are copied into
the "warning area" of the caller.
Consequently, statements that use a table or generate a warning
*will* clear warnings inside the trigger, but that will have no
effect to the warning list of the calling (outer) statement.
Correction of backport patch:
* Fixed signature of check_access_table() for embedded build
* Fixed typo for last argument in a check_access() call from UINT_MAX to 0.
# Bug#24690 Stored functions: RETURNing UTF8 strings
# do not return UTF8_UNICODE_CI collation
#
# Bug#17903: cast to char results in binary
# Regression. The character set was not being properly initialized
# for CAST() with a type like CHAR(2) BINARY, which resulted in
# incorrect results or even a server crash.
#
Backporting from mysql-6.0-codebase.
mysql-test/r/sp-ucs2.result:
mysql-test/t/sp-ucs2.test:
Adding tests
sql/mysql_priv.h:
Adding prototype
sql/sp.cc
Remember COLLATE clause for non-default collations
sql/sql_parse.cc
Adding a new helper function
sql/sql_yacc.yy
- Allow "CHARACTER SET cs COLLATE cl" in
SP parameters, RETURNS, DECLARE
- Minor reorganization for "ASCII" and "UNICODE"
related rules, to make the code more readable,
also to allow these aliases:
* "VARCHAR(10) ASCII BINARY" -> CHARACTER SET latin1 COLLATE latin1_bin
* "VARCHAR(10) BINARY ASCII" -> CHARACTER SET latin1 COLLATE latin1_bin
* "VARCHAR(10) UNICODE BINARY" -> CHARACTER SET ucs2 COLLATE ucs2_bin
* "VARCHAR(10) BINARY UNICODE" -> CHARACTER SET ucs2 COLLATE ucs2_bin
Previously these four aliases returned the error
"This version of MySQL does not yet support return value collation".
Note:
This patch allows "VARCHAR(10) CHARACTER SET cs COLLATE cl"
and the above four aliases.
"VARCHAR(10) COLLATE cl" is still not allowed
i.e. when COLLATE is given without CHARACTER SET.
If we want to support this, we need an architecture decision
which character set to use by default.
CURRENT_USER() in GRANT ... TO CURRENT_USER() only gave us a definer,
not a full user (i.e., password-element was not initiliazed). Hence
dereferencing the password led to a crash.
Properly initializes definers now, just so there are no misunderstandings.
Also does some magic so IDENTIFIED BY ... works with CURRENT_USER().
Backport for 5.5
In non debug builds, the statements:
- SHOW PROCEDURE CODE
- SHOW FUNCTION CODE
used to fail with a "syntax error", which is misleading.
These statements have been changed to return the following error for non
debug builds:
ERROR HY000: The 'SHOW PROCEDURE|FUNCTION CODE' feature is disabled; you
need MySQL built with '--with-debug' to have it working
For debug builds (./configure --with-debug), nothing is changed.
XA START may cause assertion failure/server crash when it is called
after unilateral roll back issued by the Resource Manager (both
in regular transaction and after XA transaction).
The problem was that rm_error variable wasn't set/reset properly.
Conflicts
=========
Text conflict in .bzr-mysql/default.conf
Text conflict in libmysqld/CMakeLists.txt
Text conflict in libmysqld/Makefile.am
Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/extra/rpl_tests/rpl_row_sp006.test
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata_fatal.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_create_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_log.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_circular_simplex.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_sp006.result
Text conflict in mysql-test/t/mysqlbinlog.test
Text conflict in sql/CMakeLists.txt
Text conflict in sql/Makefile.am
Text conflict in sql/log_event_old.cc
Text conflict in sql/rpl_rli.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_binlog.cc
Text conflict in sql/sql_lex.h
21 conflicts encountered.
NOTE
====
mysql-5.1-rpl-merge has been made a mirror of mysql-next-mr:
- "mysql-5.1-rpl-merge$ bzr pull ../mysql-next-mr"
This is the first cset (merge/...) committed after pulling
from mysql-next-mr.
allows SHOW CREATE TABLE) from 6.0. Original revisions:
------------------------------------------------------------
revno: 2617.31.8
committer: Alexander Nozdrin <alik@sun.com>
branch nick: 6.0-rt-bug38347
timestamp: Thu 2009-03-26 09:08:24 +0300
message:
Patch for Bug#38347: ALTER ROUTINE privilege allows SHOW CREATE TABLE.
If a user has any of the following privileges for a table (or the database
if the table), he should be able to issue SHOW CREATE TABLE for the table:
- CREATE
- DROP
- ALTER
- DELETE
- INDEX
- INSERT
- SELECT
- UPDATE
- TRIGGER
- REFERENCES
- GRANT OPTION
- CREATE VIEW
- SHOW VIEW
Any other privilege (even SUPER) should not allow SHOW CREATE TABLE.
------------------------------------------------------------
revno: 2617.31.11
committer: Alexander Nozdrin <alik@sun.com>
branch nick: 6.0-rt
timestamp: Fri 2009-03-27 21:36:34 +0300
message:
Additional patch for Bug#38347 (ALTER ROUTINE privilege
allows SHOW CREATE TABLE).
The problem was that information_schema.test,
information_schema_parameters.test and information_schema_routines.test
failed with the first patch. That happened due to limitation in check_access():
it allows only SELECT_ACL privilege for INFORMATION_SCHEMA tables.
The patch is to request only SELECT_ACL privilege for INFORMATION_SCHEMA tables.
------------------------------------------------------------
2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
some other minor revisions.
This patch implements:
WL#4264 "Backup: Stabilize Service Interface" -- all the
server prerequisites except si_objects.{h,cc} themselves (they can
be just copied over, when needed).
WL#4435: Support OUT-parameters in prepared statements.
(and all issues in the initial patches for these two
tasks, that were discovered in pushbuild and during testing).
Bug#39519: mysql_stmt_close() should flush all data
associated with the statement.
After execution of a prepared statement, send OUT parameters of the invoked
stored procedure, if any, to the client.
When using the binary protocol, send the parameters in an additional result
set over the wire. When using the text protocol, assign out parameters to
the user variables from the CALL(@var1, @var2, ...) specification.
The following refactoring has been made:
- Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
- A new Protocol::send_result_set_row() was introduced to incapsulate
common functionality for sending row data.
- Signature of Protocol::prepare_for_send() was changed: this operation
does not need a list of items, the number of items is fully sufficient.
The following backward incompatible changes have been made:
- CLIENT_MULTI_RESULTS is now enabled by default in the client;
- CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
The flag EXTRA_ACL is used in conjugation with our access checks, yet it is
not clear what impact this flag has.
This is a code clean up which replaces use of EXTRA_ACL with an explicit
function parameter.
The patch also fixes privilege checks for:
- SHOW CREATE TABLE: The new privilege requirement is any privilege on
the table-level.
- CHECKSUM TABLE: Requires SELECT on the table level.
- SHOW CREATE VIEW: Requires SHOW_VIEW and SELECT on the table level
(just as the manual claims)
- SHOW INDEX: Requires any privilege on any column combination.
view that has Group By
When SELECT'ing from a view that mentions another,
materialized, view, access was being denied. The issue was
resolved by lifting a special case which avoided such access
checking in check_single_table_access. In the past, this was
necessary since if such a check were performed, the error
message would be downgraded to a warning in the case of SHOW
CREATE VIEW. The downgrading of errors was meant to handle
only that scenario, but could not distinguish the two as it
read only the error messages.
The special case was needed in the fix of bug no 36086.
Before that, views were confused with derived tables.
After bug no 35996 was fixed, the manipulation of errors
during SHOW CREATE VIEW execution is not dependent on the
actual error messages in the queue, it rather looks at the
actual cause of the error and takes appropriate
action. Hence the aforementioned special case is now
superfluous and the bug is fixed.
Implemented the server infrastructure for the fix:
1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of
thd_query()
2. Did some encapsulation in THD : aggregated thd_query and
thd_query_length into a LEX_STRING and made accessor and mutator
methods for easy code updating.
3. Updated the server code to use the new methods where applicable.
local storage for query cache).
We need more than one pointer in a thread to
represent the query cache and net->query_cache_query can not be used
any more (due to ABI compatibility issues and to different life
time of NET and THD).
This is a backport of the following patch from 6.0:
----------------------------------------------------------
revno: 2476.1157.2
committer: kostja@bodhi.(none)
timestamp: Sat 2007-06-16 13:29:24 +0400
Original revision in 6.0:
------------------------------------------------------------
revno: 2630.13.11
committer: Alexander Nozdrin <alik@mysql.com>
branch nick: 6.0-rt-wl4300
timestamp: Thu 2008-07-24 11:44:21 +0400
message:
A patch for WL#4300: Define privileges for tablespaces.
------------------------------------------------------------
per-file messages:
mysql-test/r/grant.result
Update result file: new columm 'Create_tablespace_priv' has been added to mysql.user.
mysql-test/r/ps.result
Update result file: new columm 'Create_tablespace_priv' has been added to mysql.user.
mysql-test/r/system_mysql_db.result
Update result file: new columm 'Create_tablespace_priv' has been added to mysql.user.
mysql-test/suite/falcon/r/falcon_tablespace_priv.result
Test case for WL#4300.
mysql-test/suite/falcon/t/falcon_tablespace_priv.test
Test case for WL#4300.
mysql-test/suite/ndb/r/ndb_dd_ddl.result
Test case for WL#4300.
mysql-test/suite/ndb/t/ndb_dd_ddl.test
Test case for WL#4300.
scripts/mysql_system_tables.sql
New columm 'Create_tablespace_priv' has been added to mysql.user.
scripts/mysql_system_tables_data.sql
'CREATE TABLESPACE' is granted by default to the root user.
scripts/mysql_system_tables_fix.sql
Grant 'CREATE TABLESPACE' privilege during system table upgrade
if a user had SUPER privilege.
sql/sql_acl.cc
Added CREATE TABLESPACE privilege.
sql/sql_acl.h
Added CREATE TABLESPACE privilege.
sql/sql_parse.cc
Check global 'CREATE TABLESPACE' privilege for the following SQL statements:
- CREATE | ALTER | DROP TABLESPACE
- CREATE | ALTER | DROP LOGFILE GROUP
sql/sql_show.cc
Added CREATE TABLESPACE privilege.
sql/sql_yacc.yy
Added CREATE TABLESPACE privilege.
storing and restoring information about foreign keys in the .FRM files and
properly displaying it in SHOW CREATE TABLE output and I_S tables.
The idea of this patch is to change type of Key_part_spec::field_name and
Key::name to LEX_STRING in order to avoid extra strlen() calls during
semantic analysis and statement execution, particularly, in code to be
implemented on the 2nd milestone of WL#148.
Note that since we are not using LEX_STRING everywhere yet (e.g. in
Create_field and KEY) and we want to limit scope of our changes we
have to do strlen() in places where we create Key and Key_part_spec
instances from objects using plain (char*) for strings. These calls
will go away during the process of further (char*) -> LEX_STRING
refactoring.
We have introduced these changes in 6.0 and backported them to 5.5
tree to make people aware of these changes as early as possible and
to simplify merges with mysql-fk and mysql-6.1-fk trees.
No test case is needed since this patch does not introduce any
user visible changes.
"have_profiling"
1) Renamed have_community_features server system variable to
have_profiling.
2) Removed eable-community-features configure option and
ENABLE_COMMUNITY_FEATURES macro.
3) Removed COMMUNITY_SERVER macro and replaced its usage by
ENABLED_PROFILING.
Only --enable-profiling is now needed to enable profiling.
It was the only existing "community feature", so there was
no need for both configure options.
Using --enable-community-features will give a warning message
since it no longer exists.
