mariadb

Commit Graph

Author	SHA1	Message	Date
unknown	6d93f15039	Bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY UPDATE if the row wasn't actually changed. This bug was caused by fix for bug#19978. It causes AFTER UPDATE triggers not firing if a row wasn't actually changed by the update part of the INSERT .. ON DUPLICATE KEY UPDATE. Now triggers are always fired if a row is touched by the INSERT ... ON DUPLICATE KEY UPDATE. sql/sql_insert.cc: Bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY UPDATE if the row wasn't actually changed. Now triggers are always fired if a row is touched by the INSERT ... ON DUPLICATE KEY UPDATE. mysql-test/r/trigger.result: Added a test case for the bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY UPDATE if the row wasn't actually changed. mysql-test/t/trigger.test: Added a test case for the bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY UPDATE if the row wasn't actually changed.	19 years ago
unknown	2e8e78a42c	Bug #26261 : INSERT uses query_id to verify what fields are mentioned in the fields list of the INSERT command. However the check for that is made after the ON DUPLICATE KEY is processed. This causes all the fields mentioned in ON DUPLICATE KEY to be considered as mentioned in the fields list of INSERT. Moved the check up, right after processing the fields list. mysql-test/r/insert_update.result: Bug #26261: test case mysql-test/t/insert_update.test: Bug #26261: test case sql/mysql_priv.h: Bug #26261: moved the check inside mysql_prepare_insert sql/sql_insert.cc: Bug #26261: move the check inside mysql_prepare_insert before setting up the ON DUPLICATE KEY part sql/sql_prepare.cc: Bug #26261: moved the check inside mysql_prepare_insert	19 years ago
unknown	a51b768600	Bug#26285 selecting information_schema crahes server The crash happens when 'skip-grant-tables' is enabled. We skip the filling of I_S privilege tables if acl_cache is not initialized. mysql-test/r/skip_grants.result: test result mysql-test/t/skip_grants.test: test case sql/sql_acl.cc: skip filling of I_S privilege tables if acl_cache is not initialized	19 years ago
unknown	542f18a31a	Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. The LAST_INSERT_ID() is reset to 0 if no rows were inserted or changed. This is the case when an INSERT ... ON DUPLICATE KEY UPDATE updates a row with the same values as the row contains. Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows successfully inserted or touched. The new 'touched' field is added to the COPY_INFO structure. It holds the number of rows that were touched no matter whether they were actually changed or not. sql/sql_class.h: Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. The new 'touched' field is added to the COPY_INFO structure. It holds the number of rows that were touched no matter whether they were actually changed or not. mysql-test/r/insert_update.result: Added a test case for the bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. mysql-test/t/insert_update.test: Added a test case for the bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. sql/sql_insert.cc: Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows successfully inserted or touched.	19 years ago
unknown	b42da2dd01	merging	19 years ago
unknown	480a4ef94c	merge 5.0->5.1	19 years ago
unknown	7a3148a7aa	Bug #24778 : Innodb: No result when using ORDER BY This bug was intruduced by the fix for bug#17212 (in 4.1). It is not ok to call test_if_skip_sort_order since this function will alter the execution plan. By contract it is not ok to call test_if_skip_sort_order in this context. This bug appears only in the case when the optimizer has chosen an index for accessing a particular table but finds a covering index that enables it to skip ORDER BY. This happens in test_if_skip_sort_order. mysql-test/r/key.result: Bug#24778 test case. The bug causes the result to be the empty set. mysql-test/t/key.test: Bug#24778 The minimal test case that reveals the bug. The reason for such a complicated schema is that we have to convince the optimizer to pick one index, then discard it in order to be able to skip ORDER BY. sql/sql_select.cc: bug#24778 Removed the call to test_if_skip_sort_order that constituted the bug.	19 years ago
unknown	6e10a2048d	Bug #26794 : 5.1 part It was syntactically correct to define spatial keys over parts of columns (e.g. ALTER TABLE t1 ADD x GEOMETRY NOT NULL, ADD SPATIAL KEY (x(32))). This may lead to undefined results and/or interpretation. Fixed by not allowing partial column specification in a SPATIAL index definition. mysql-test/r/alter_table.result: Bug #26794: 5.1 part test case mysql-test/r/gis-rtree.result: Bug #26794: 5.1 part updated the tests to the new syntax mysql-test/t/alter_table.test: Bug #26794: 5.1 part test case mysql-test/t/gis-rtree.test: Bug #26794: 5.1 part updated the tests to the new syntax sql/sql_table.cc: Bug #26794: 5.1 part Disable defining SPATIAL KEYS with sub-key parts	19 years ago
unknown	a22f257e04	Bug #26794 : Different set of conditions is used to verify the validity of index definitions over a GEOMETRY column in ALTER TABLE and CREATE TABLE. The difference was on how sub-keys notion validity is checked. Fixed by extending the CREATE TABLE condition to support the cases allowed in ALTER TABLE. Made the SHOW CREATE TABLE not to display spatial indexes using the sub-key notion. mysql-test/r/alter_table.result: Bug #26794: test case mysql-test/r/gis-rtree.result: Bug #26794: fixed SHOW CREATE TABLE output. mysql-test/t/alter_table.test: Bug #26794: test case sql/field.cc: Bug #26794: Allow sub-keys for GEOMETRY sql/sql_show.cc: Bug #26794: Don't show sub-key notion in SHOW CREATE TABLE for SPATIAL indexes. sql/sql_table.cc: Bug #26794: Allow sub-keys for GEOMETRY	19 years ago
unknown	969b71653d	BUG#26881 - Large MERGE tables report incorrect specification when no differences in tables Certain merge tables were wrongly reported as having incorrect definition: - Some fields that are 1 byte long (e.g. TINYINT, CHAR(1)), might be internally casted (in certain cases) to a different type on a storage engine layer. (affects 4.1 and up) - If tables in a merge (and a MERGE table itself) had short VARCHAR column (less than 4 bytes) and at least one (but not all) tables were ALTER'ed (even to an identical table: ALTER TABLE xxx ENGINE=yyy), table definitions went ouf of sync. (affects 4.1 only) This is fixed by relaxing a check for underlying conformance and setting field type to FIELD_TYPE_STRING in case varchar is shorter than 4 when a table is created. myisam/mi_create.c: Added a comment. mysql-test/r/merge.result: A test case for bug#26881. mysql-test/t/merge.test: A test case for bug#26881. sql/ha_myisam.cc: Relaxed some checks performed by check_definition(): As comparing of fulltext keys (and key segments) is not yet implemented, only return an error in case one of keys is fulltext and other is not. Otherwise, if both keys are fulltext, accept them as is. As comparing of spatial keys (and key segments) is not yet implemented, only return an error in case one of keys is spatial and other is not. Otherwise, if both keys are spatial, accept them as is. A workaround to handle situation when field is casted from FIELD_SKIP_ZERO to FIELD_NORMAL. This could happen only in case field length is 1 and row format is fixed. sql/sql_parse.cc: When a table that has varchar field shorter than 4 is created, field type is set to FIELD_TYPE_VAR_STRING. Later, when a table is modified using alter table, field type is changed to FIELD_TYPE_STRING (see Field_string::type). That means HA_OPTION_PACK_RECORD flag might be lost and thus null_bit might be shifted by alter table, in other words alter table doesn't create 100% equal table definition. This is usually not a problem, since when a table is created/altered, definition on a storage engine layer is based on one that is passed from sql layer. But it is a problem for merge engine - null_bit is shifted when a table (merge or underlying) is altered. Set field type to FIELD_TYPE_STRING in case FIELD_TYPE_VAR_STRING is shorter than 4 when a table is created as it is done in Field::type.	19 years ago
unknown	bd6aecf3f3	Bug #26794 : Different set of conditions is used to verify the validity of index definitions over a GEOMETRY column in ALTER TABLE and CREATE TABLE. The difference was on how sub-keys notion validity is checked. Fixed by extending the CREATE TABLE condition to support the cases allowed in ALTER TABLE. Made the SHOW CREATE TABLE not to display spatial indexes using the sub-key notion. mysql-test/r/alter_table.result: Bug #26794: test case mysql-test/r/gis-rtree.result: Bug #26794: fixed SHOW CREATE TABLE output. mysql-test/t/alter_table.test: Bug #26794: test case sql/field.cc: Bug #26794: Allow sub-keys for GEOMETRY sql/sql_show.cc: Bug #26794: Don't show sub-key notion in SHOW CREATE TABLE for SPATIAL indexes. sql/sql_table.cc: Bug #26794: Allow sub-keys for GEOMETRY	19 years ago
unknown	4ce3624ec4	group_by.result: WL3527: disable wrong optimization. sql_select.cc: WL#3527: disable wrong optimization. sql/sql_select.cc: WL#3527: disable wrong optimization. mysql-test/r/group_by.result: WL3527: disable wrong optimization.	19 years ago
unknown	91abf15ed2	Fixed bug #26738 : incomplete string values in a result set column when the column is to be read from a derived table column which was specified as a concatenation of string literals. The bug happened because the Item_string::append did not adjust the value of Item_string::max_length. As a result of it the temporary table column defined to store the concatenation of literals was not wide enough to hold the whole value. mysql-test/r/subselect.result: Added a test case for bug #26738. mysql-test/t/subselect.test: Added a test case for bug #26738.	19 years ago
unknown	13c05162f3	Fixed bug #26963 : invalid optimization of the pushdown conditions after single-row table substitution could lead to a wrong result set. The bug happened because the function Item_field::replace_equal_field erroniously assumed that any field included in a multiple equality with a constant has been already substituted for this constant. This not true for fields becoming constant after row substitutions for constant tables. mysql-test/r/select.result: Added a test case for bug #26963. mysql-test/t/select.test: Added a test case for bug #26963. sql/item.cc: Fixed bug #26963: invalid optimization of the pushdown conditions after single-row table substitution could lead to a wrong result set. The bug happened because the function Item_field::replace_equal_field erroneously assumed that any field included in a multiple equality with a constant has been already substituted for this constant. This not true for fields becoming constant after row substitutions for constant tables.	19 years ago
unknown	816ea8a379	Bug#15757: Wrong SUBSTRING() result when a tmp table was employed. When the SUBSTRING() function was used over a LONGTEXT field the max_length of the SUBSTRING() result was wrongly calculated and set to 0. As the max_length parameter is used while tmp field creation it limits the length of the result field and leads to printing an empty string instead of the correct result. Now the Item_func_substr::fix_length_and_dec() function correctly calculates the max_length parameter. mysql-test/t/func_str.test: Added a test case for the bug#15757: Wrong SUBSTRING() result when a tmp table was employed. mysql-test/r/func_str.result: Added a test case for the bug#15757: Wrong SUBSTRING() result when a tmp table was employed. sql/item_strfunc.cc: Bug#15757: Wrong SUBSTRING() result when a tmp table was employed. Now the Item_func_substr::fix_length_and_dec() function correctly calculates the max_length parameter.	19 years ago
unknown	4d6ad7ac60	Fixed bug #26830 : a crash for the query with a subselect containing ROLLUP. Crash happened because the function get_best_group_min_max detected joins with ROLLUP incorrectly. mysql-test/r/olap.result: Added a test case for bug #26830. mysql-test/t/olap.test: Added a test case for bug #26830.	19 years ago
unknown	ff94fdda37	disabling _new_ unstable test case	19 years ago
unknown	944030aef7	Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Additional fix for bug#22331. Now Item_field prints its value in the case of the const field. mysql-test/r/varbinary.result: Corrected test case after fix for bug#22331. mysql-test/r/union.result: Corrected test case after fix for bug#22331. mysql-test/r/subselect.result: Corrected test case after fix for bug#22331. mysql-test/r/func_test.result: Corrected test case after fix for bug#22331. mysql-test/r/having.result: Corrected test case after fix for bug#22331. mysql-test/r/func_regexp.result: Corrected test case after fix for bug#22331. mysql-test/r/func_str.result: Corrected test case after fix for bug#22331. mysql-test/r/func_default.result: Corrected test case after fix for bug#22331. mysql-test/r/explain.result: Corrected test case after fix for bug#22331. sql/sql_union.cc: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Cleanup of the SELECT_LEX::order_list list. sql/item.h: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Added the print() member function to the Item_field class. sql/item.cc: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Added the print() member function to the Item_field class.	19 years ago
unknown	435f37a5fb	corrected returned error code	19 years ago
unknown	ff79cd6870	WL#3527: Extend IGNORE INDEX so places where index is ignored can be specified 5.0 part of the fix. Implements IGNORE INDEX FOR JOIN as a synonym of IGNORE INDEX for backward compatibility with the 5.1 fix. mysql-test/r/select.result: WL#3527: Extend IGNORE INDEX so places where index is ignored can be specified - test case mysql-test/t/select.test: WL#3527: Extend IGNORE INDEX so places where index is ignored can be specified - test case	19 years ago
unknown	29b6d55402	Bug #26281 : Fixed boundry checks in the INSERT() function: were one off. mysql-test/r/func_str.result: Bug #26281: test case mysql-test/t/func_str.test: Bug #26281: test case sql/item_strfunc.cc: Bug #26281: fixed boundry checks	19 years ago
unknown	729bcaf430	Fixed bug #26661 : crash when order by clause in a union construct references invalid name. Derived tables currently cannot use outer references. Thus there is no outer context for them. The 4.1 code takes this fact into account while the Item_field::fix_outer_field code of 5.0 lost the check that blocks any attempts to resolve names in outer context for derived tables. mysql-test/r/union.result: Added a test case for bug #26661. mysql-test/t/union.test: Added a test case for bug #26661. sql/item.cc: Fixed bug #26661. Derived tables currently cannot use outer references. Thus there is no outer context for them. The 4.1 code takes this fact into account while the Item_field::fix_outer_field code of 5.0 lost the check that blocks any attempts to resolve names in outer context for derived tables.	19 years ago
unknown	3dbfc95c33	ndb single user basic test	19 years ago
unknown	32ed7ddccc	aftermerge fix mysql-test/r/sp.result: merging mysql-test/r/view.result: merging	19 years ago
unknown	5c1e48c51d	aftermerge fix mysql-test/r/view.result: merging	19 years ago
unknown	d4ede3f509	rpl_ssl.result, rpl_ssl.test: Mask out _Master_Log_Pos in rpl_ssl test; it varies depending on binlog format mysql-test/t/rpl_ssl.test: Mask out _Master_Log_Pos in rpl_ssl test; it varies depending on binlog format mysql-test/r/rpl_ssl.result: Mask out *_Master_Log_Pos in rpl_ssl test; it varies depending on binlog format	19 years ago
unknown	012ae63522	merging	19 years ago
unknown	0381f8cfe5	Update result for 5.1	19 years ago
unknown	2157f64238	Bug#25673 - spatial index corruption, error 126 incorrect key file for table After merge fix	19 years ago
unknown	548a39a104	Bug#25673 - spatial index corruption, error 126 incorrect key file for table In certain cases it could happen that deleting a row could corrupt an RTREE index. According to Guttman's algorithm, page underflow is handled by storing the page in a list for later re-insertion. The keys from the stored pages have to be inserted into the remaining pages of the same level of the tree. Hence the level number is stored in the re-insertion list together with the page. In the MySQL RTree implementation the level counts from zero at the root page, increasing numbers for levels down the tree. If during re-insertion of the keys the tree height grows, all level numbers become invalid. The remaining keys will be inserted at the wrong level. The fix is to increment the level numbers stored in the reinsert list after a split of the root block during reinsertion. myisam/rt_index.c: Bug#25673 - spatial index corruption, error 126 incorrect key file for table Added a loop in rtree_delete() to increment the level numbers stored in the reinsert list after a split of the root block during reinsertion. Added comments and DBUG statements. myisam/rt_key.c: Bug#25673 - spatial index corruption, error 126 incorrect key file for table Added DBUG statements. myisam/rt_split.c: Bug#25673 - spatial index corruption, error 126 incorrect key file for table Added DBUG statements. mysql-test/r/gis-rtree.result: Bug#25673 - spatial index corruption, error 126 incorrect key file for table Added the test result. mysql-test/t/gis-rtree.test: Bug#25673 - spatial index corruption, error 126 incorrect key file for table Added a test.	19 years ago
unknown	5501a2915a	update test results for bdb_gis after merge of fix for b26038	19 years ago
unknown	1631f65dfd	sql_select.cc: Postfix for bug#22331 for windows platform. explain.test, explain.result: Cleanup after bugfix#22331. mysql-test/t/explain.test: Cleanup after bugfix#22331. mysql-test/r/explain.result: Cleanup after bugfix#22331. sql/sql_select.cc: Postfix for bug#22331 for windows platform.	19 years ago
unknown	11b533b8be	Bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. For built-in functions like sqrt() function names are hard-coded and can be compared by pointer. But this isn't the case for a used-defined stored functions - names there are dynamical and should be compared as strings. Now the Item_func::eq() function employs my_strcasecmp() function to compare used-defined stored functions names. mysql-test/t/sp.test: Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. mysql-test/r/sp.result: Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. sql/item_func.cc: Bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. Now the Item_func::eq() function employs my_strcasecmp() function to compare used-defined stored functions names.	19 years ago
unknown	6de277910b	Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. During optimization stage the WHERE conditions can be changed or even be removed at all if they know for sure to be true of false. Thus they aren't showed in the EXPLAIN EXTENDED which prints conditions after optimization. Now if all elements of an Item_cond were removed this Item_cond is substituted for an Item_int with the int value of the Item_cond. If there were conditions that were totally optimized away then values of the saved cond_value and having_value will be printed instead. mysql-test/t/explain.test: Added a test case for the bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. mysql-test/r/subselect.result: Corrected test case result after fix for bug#22331. mysql-test/r/func_test.result: Corrected test case result after fix for bug#22331. mysql-test/r/explain.result: Added a test case for the bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. sql/sql_select.cc: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Now if all elements of an Item_cond were removed this Item_cond is substituted for an Item_int with the int value of the Item_cond. If there were conditions that were totally optimized away then values of the saved cond_value and having_value will be printed instead. sql/sql_lex.h: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. The cond_value and the having_value variables are added to the SELECT_LEX class. sql/sql_lex.cc: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. The initialization of the cond_value and the having_value variables. sql/sql_select.h: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Now having_value is also stored in the JOIN class.	19 years ago
unknown	e2706b6721	Bug #26672 : DATE/DATETIME values are out of the currently supported 4 basic value types (INT,STRING,REAL and DECIMAL). So expressions (not fields) of compile type DATE/DATETIME are generally considered as STRING values. This is not so when they are compared : then they are compared as INTEGER values. But the rule for comparison as INTEGERS must be checked explicitly each time when a comparison is to be performed. filesort is one such place. However there the check was not done and hence the expressions (not fields) of type DATE/DATETIME were sorted by their string representation. Fixed to compare them as INTEGER values for filesort. mysql-test/r/order_by.result: Bug #26672: test case mysql-test/t/order_by.test: Bug #26672: test case sql/filesort.cc: Bug #26672: sort dates/times as integers	19 years ago
unknown	142e778d88	Post-merge fix of mysqlbinlog.{test,result}	19 years ago
unknown	f7414b2897	Manual merge	19 years ago
unknown	38acf43e34	Bug#25376: Incomplete setup of ORDER BY clause results in a wrong result. Functions over sum functions wasn't set up correctly for the ORDER BY clause which leads to a wrong order of the result set. The split_sum_func() function is called now for each ORDER BY item that contains a sum function to set it up correctly. mysql-test/t/order_by.test: Added a test case for bug#25376: Incomplete setup of ORDER BY clause results in a wrong result. mysql-test/r/order_by.result: Added a test case for bug#25376: Incomplete setup of ORDER BY clause results in a wrong result. sql/sql_select.cc: Bug#25376: Incomplete setup of ORDER BY clause results in a wrong result. The split_sum_func() function is called now for each ORDER BY item that contains a sum function to set it up correctly.	19 years ago
unknown	71f90b7e6f	Manual merge	19 years ago
unknown	9528ed5b32	Post-merge fixes. mysql-test/r/subselect.result: A post-merge fix: update test results. sql/sql_yacc.yy: Update to the number of conflicts in 5.1	19 years ago
unknown	a232d81e80	Bug#19342: additional test case for code coverage	19 years ago
unknown	266a7fff52	Bug#8407 (Stored functions/triggers ignore exception handler) Bug 18914 (Calling certain SPs from triggers fail) Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02') Bug 21825 (Incorrect message error deleting records in a table with a trigger for inserting) Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency error) Bug 25345 (Cursors from Functions) This fix resolves a long standing issue originally reported with bug 8407, which affect the behavior of Stored Procedures, Stored Functions and Trigger in many different ways, causing symptoms reported by all the bugs listed. In all cases, the root cause of the problem traces back to 8407 and how the server locks tables involved with sub statements. Prior to this fix, the implementation of stored routines would: - compute the transitive closure of all the tables referenced by a top level statement - open and lock all the tables involved - execute the top level statement "transitive closure of tables" means collecting: - all the tables, - all the stored functions, - all the views, - all the table triggers - all the stored procedures involved, and recursively inspect these objects definition to find more references to more objects, until the list of every object referenced does not grow any more. This mechanism is known as "pre-locking" tables before execution. The motivation for locking all the tables (possibly) used at once is to prevent dead locks. One problem with this approach is that, if the execution path the code really takes during runtime does not use a given table, and if the table is missing, the server would not execute the statement. This in particular has a major impact on triggers, since a missing table referenced by an update/delete trigger would prevent an insert trigger to run. Another problem is that stored routines might define SQL exception handlers to deal with missing tables, but the server implementation would never give user code a chance to execute this logic, since the routine is never executed when a missing table cause the pre-locking code to fail. With this fix, the internal implementation of the pre-locking code has been relaxed of some constraints, so that failure to open a table does not necessarily prevent execution of a stored routine. In particular, the pre-locking mechanism is now behaving as follows: 1) the first step, to compute the transitive closure of all the tables possibly referenced by a statement, is unchanged. 2) the next step, which is to open all the tables involved, only attempts to open the tables added by the pre-locking code, but silently fails without reporting any error or invoking any exception handler is the table is not present. This is achieved by trapping internal errors with Prelock_error_handler 3) the locking step only locks tables that were successfully opened. 4) when executing sub statements, the list of tables used by each statements is evaluated as before. The tables needed by the sub statement are expected to be already opened and locked. Statement referencing tables that were not opened in step 2) will fail to find the table in the open list, and only at this point will execution of the user code fail. 5) when a runtime exception is raised at 4), the instruction continuation destination (the next instruction to execute in case of SQL continue handlers) is evaluated. This is achieved with sp_instr::exec_open_and_lock_tables() 6) if a user exception handler is present in the stored routine, that handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be trapped by stored routines. If no handler exists, then the runtime execution will fail as expected. With all these changes, a side effect is that view security is impacted, in two different ways. First, a view defined as "select stored_function()", where the stored function references a table that may not exist, is considered valid. The rationale is that, because the stored function might trap exceptions during execution and still return a valid result, there is no way to decide when the view is created if a missing table really cause the view to be invalid. Secondly, testing for existence of tables is now done later during execution. View security, which consist of trapping errors and return a generic ER_VIEW_INVALID (to prevent disclosing information) was only implemented at very specific phases covering opening tables, but not covering the runtime execution. Because of this existing limitation, errors that were previously trapped and converted into ER_VIEW_INVALID are not trapped, causing table names to be reported to the user. This change is exposing an existing problem, which is independent and will be resolved separately. mysql-test/r/information_schema_db.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/r/sp-error.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/r/sp.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/r/trigger.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/r/view.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/t/sp-error.test: Revised the pre-locking code implementation, aligned the tests. mysql-test/t/sp.test: Revised the pre-locking code implementation, aligned the tests. mysql-test/t/trigger.test: Revised the pre-locking code implementation, aligned the tests. sql/lock.cc: table->placeholder now checks for schema_table sql/mysqld.cc: my_message_sql(): invoke internal exception handlers sql/sp_head.cc: exec_open_and_lock_tables(): open and lock tables, or return the continuation destination of this instruction sql/sp_head.h: exec_open_and_lock_tables(): open and lock tables, or return the continuation destination of this instruction sql/sql_base.cc: Prelock_error_handler: delay open table errors until execution sql/sql_class.cc: THD: add internal error handler, as an exception mechanism. sql/sql_class.h: THD: add internal error handler, as an exception mechanism. sql/sql_update.cc: table->placeholder now checks for schema_table sql/table.cc: st_table_list::hide_view_error(): masked more errors for view security sql/table.h: table->placeholder now checks for schema_table, and unopened tables	19 years ago
unknown	79542930ea	WL#3527: Extend IGNORE INDEX so places where index is ignored can be specified Currently MySQL allows one to specify what indexes to ignore during join optimization. The scope of the current USE/FORCE/IGNORE INDEX statement is only the FROM clause, while all other clauses are not affected. However, in certain cases, the optimizer may incorrectly choose an index for sorting and/or grouping, and produce an inefficient query plan. This task provides the means to specify what indexes are ignored/used for what operation in a more fine-grained manner, thus making it possible to manually force a better plan. We do this by extending the current IGNORE/USE/FORCE INDEX syntax to: IGNORE/USE/FORCE INDEX [FOR {JOIN \| ORDER \| GROUP BY}] so that: - if no FOR is specified, the index hint will apply everywhere. - if MySQL is started with the compatibility option --old_mode then an index hint without a FOR clause works as in 5.0 (i.e, the index will only be ignored for JOINs, but can still be used to compute ORDER BY). See the WL#3527 for further details. BitKeeper/deleted/.del-mysqld.cc.rej: Rename: sql/mysqld.cc.rej -> BitKeeper/deleted/.del-mysqld.cc.rej BitKeeper/deleted/.del-sql_parse.cc.rej: Rename: sql/sql_parse.cc.rej -> BitKeeper/deleted/.del-sql_parse.cc.rej BitKeeper/deleted/.del-table.cc.rej: Rename: sql/table.cc.rej -> BitKeeper/deleted/.del-table.cc.rej mysql-test/r/endspace.result: WL3527 : fixed undeterministic test mysql-test/r/group_by.result: WL#3527: test cases mysql-test/t/endspace.test: WL3527 : fixed undeterministic test mysql-test/t/group_by.test: WL#3527: test cases sql/item.cc: WL#3527: renames sql/mysql_priv.h: WL#3527: corrected initialization sql/mysqld.cc: WL#3527: added old_mode command line option sql/opt_range.cc: WL#3527: renames sql/sql_base.cc: WL#3527: - renames - correct initialization - extended the processing of USE/FORCE/IGNORE index sql/sql_class.h: WL#3527: added old_mode command line option sql/sql_delete.cc: WL#3527: renames sql/sql_help.cc: WL#3527: renames sql/sql_lex.cc: WL#3527: extended parsing of USE/FORCE/IGNORE index sql/sql_lex.h: WL#3527: extended parsing of USE/FORCE/IGNORE index sql/sql_parse.cc: WL#3527: extended parsing of USE/FORCE/IGNORE index sql/sql_select.cc: WL#3527: - renames - passing additional info to support the extended USE/FORCE/IGNORE INDEX syntax - If there is a covering index, and we have IGNORE INDEX FOR GROUP/ORDER, and this index is used for the JOIN part, then we have to ignore the IGNORE INDEX FOR GROUP/ORDER. sql/sql_show.cc: WL#3527: passing additional info to support the extended USE/FORCE/IGNORE INDEX syntax sql/sql_update.cc: WL#3527: renames sql/sql_yacc.yy: WL#3527: extended parsing of USE/FORCE/IGNORE index sql/table.cc: WL#3527: extended the processing of USE/FORCE/IGNORE index sql/table.h: WL#3527: extended the processing of USE/FORCE/IGNORE index storage/myisam/ha_myisam.cc: WL#3527: extended the processing of USE/FORCE/IGNORE index	19 years ago
unknown	85c3f6df45	Bug#21103: DATE column not compared as DATE When comparing a DATE field with a DATETIME constant, we now compare as DATETIMEs, not as DATEs. Fix BDB queries to still work.	19 years ago
unknown	da9c659c81	Bug#26464 - insert delayed + update + merge = corruption Using INSERT DELAYED on MERGE tables could lead to table corruptions. The manual lists a couple of storage engines, which can be used with INSERT DELAYED. MERGE is not in this list. The attempt to try it anyway has not been rejected yet. This bug was not detected earlier as it can work under special circumstances. Most notable is low concurrency. To be safe, this patch rejects any attempt to use INSERT DELAYED on MERGE tables. mysql-test/r/merge.result: Bug#26464 - insert delayed + update + merge = corruption Added test result. mysql-test/t/merge.test: Bug#26464 - insert delayed + update + merge = corruption Added test. sql/ha_myisammrg.h: Bug#26464 - insert delayed + update + merge = corruption Removed HA_CAN_INSERT_DELAYED flag from table_flags(). The insert delayed thread upgrades the lock from the first entry in MYSQL_LOCK::locks only. Hence it is incapable to handle MERGE tables, which have as many entries in this array as they have MyISAM sub-tables.	19 years ago
unknown	de3e6da606	Remove ssl_des.test and ssl_des.result BitKeeper/deleted/.del-ssl_des.test: Delete: mysql-test/t/ssl_des.test BitKeeper/deleted/.del-ssl_des.result: Delete: mysql-test/r/ssl_des.result	19 years ago
unknown	9cace97d19	Bug#21781 Replication slave io thread hangs - Add test case that shows how slave server hangs in "STOP SLAVE" when run on MySQL version 5.0.33 compiled with OpenSSL. Works fine with latest version of MySQL since that problem has been fixed by patch for bug#24148. The fix has been noted in the changelog for MySQL 5.0.36 mysql-test/r/rpl_ssl.result: New BitKeeper file ``mysql-test/r/rpl_ssl.result'' mysql-test/t/rpl_ssl.test: New BitKeeper file ``mysql-test/t/rpl_ssl.test''	19 years ago
unknown	3880c80fc6	Add "have_ssl" as synonym for "have_openssl" mysql-test/t/openssl_1.test: Add "have_ssl" as synonym for "have_openssl" Correct comment	19 years ago
unknown	c5e5b5e167	Bug #26792 Add DBX debugger support to mysql-test-run.pl - Add --debugger=dbx - Fix --debugger=devenv, --debugger=DevEnv and --debugger=/path/devenv mysql-test/mysql-test-run.pl: Add support for --debugger=dbx to mysql-test-run.pl Fix case senitive match for vc, vcexpress or deven Make it possible to use full path to debugger for --debugger=/path/vcexpress	19 years ago
unknown	6da758c216	Fixed bug #26560 . The flag alias_name_used was not set on for the outer references in subqueries. It resulted in replacement of any outer reference resolved against an alias for a full field name when the frm representation of a view with a subquery was generated. If the subquery and the outer query referenced the same table in their from lists this replacement effectively changed the meaning of the view and led to wrong results for selects from this view. Modified several functions to ensure setting the right value of the alias_name_used flag for outer references resolved against aliases. mysql-test/r/view.result: Added a test case for bug #26560. mysql-test/t/view.test: Added a test case for bug #26560. sql/item.cc: Fixed bug #26560. Made the function resolve_ref_in_select_and_group analyze the return value of the last parameter with the type of the name resolution for the submitted reference. If the reference has been resolved against an alias name from select list then its flag alias_name_used is set on. Now this value is used in Item_field::fix_outer_field to initialize the flag when the item_ref object is created for an outer reference. Added a parameter for the second Item_ref::Item_ref constructor to initialize properly the flag alias_name_used. The default value of the parameter is FALSE. If this flag is set on at the creation of an object by this constructor it will never be changed. Corrected appropriately the Item_ref::set_properties function. The function Item_ref::print now prints alias name for an outer reference if the flag alias_name_used is set on. sql/item.h: Fixed bug #26560. Added a parameter for the second Item_ref::Item_ref constructor to initialize properly the flag alias_name_used. The default value of the parameter is FALSE. A similar change has been applied to the first Item_direct_ref::Item_direct_ref constructor. sql/mysql_priv.h: Fixed bug #26560. Added an an enumeration type enum_resolution_type to return info on how the function find_item_in_list has resolved the submitted item. The type is used only for this function. sql/sql_base.cc: Fixed bug #26560. Made the last parameter of the function find_field_in_tables return more detailed information on how the submitted item has been resolved. Now it says whether the item has been resolved against an alias name, or as a field name without alias, or as a field name hidden by alias, or was resolved ignoring alias. sql/sql_select.cc: Fixed bug #26560. Took into account the new type of the last parameter of the function find_item_in_list.	19 years ago

1 2 3 4 5 ...

16775 Commits (1662b187574f61042daba6dd93f61cbbe947f2e4)