An error occurred fetching the project authors.
- 16 Nov, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
Before this change, the functions BENCHMARK, ENCODE, DECODE and FORMAT could only accept a constant for some parameters. After this change, this restriction has been removed. An implication is that these functions can also be used in prepared statements. The change consist of changing the following classes: - Item_func_benchmark - Item_func_encode - Item_func_decode - Item_func_format to: - only accept Item* in the constructor, - and evaluate arguments during calls to val_xxx() which fits the general design of all the other functions. The 'TODO' items identified in item_create.cc during the work done for Bug 21114 are addressed by this fix, as a natural consequence of aligning the design. In the 'func_str' test, a single very long test line involving an explain extended select with many functions has been rewritten into multiple separate tests, to improve maintainability. The result of explain extended select decode(encode(...)) has changed, since the encode and decode functions now print all their parameters.
-
- 02 Nov, 2006 2 commits
-
-
malff/marcsql@weblab.(none) authored
-
kostja@bodhi.local authored
-
- 19 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION or CREATE TRIGGER statements with a syntax error in it, the preparation would fail with syntax error message, but the memory could be corrupted. The problem occurred because we switch memroot when parse stored routine or trigger definitions, and on parse error we restored the original memroot only after performing some memory operations. In more detail: - prepared statement would activate its own memory root to parse the definition of the stored procedure. - SP would reset this memory root with its own memory root to parse SP statements - a syntax error would happen - prepared statement would restore the original memory root - stored procedure would restore what it thinks was the original memory root, but actually was the statement memory root. That led to double free - in destruction of the statement and in a next call to mysql_parse(). The solution is to restore memroot right after the failed parsing.
-
- 17 Oct, 2006 1 commit
-
-
tsmith/tim@siva.hindu.god authored
-
- 12 Oct, 2006 1 commit
-
-
tsmith/tim@siva.hindu.god authored
Do not consider SHOW commands slow queries, just because they don't use proper indexes. This bug fix is not needed in 5.1, and the code changes will be null merged. However, the test cases will be propogated up to 5.1.
-
- 11 Oct, 2006 2 commits
-
-
ted@ted.mysql.internal authored
-
ted@ted.mysql.internal authored
BUG#21524 ER_CANT_OPEN_LIBRARY output message used to confuse mysqltest on Solaris. Varying part of the message is now suppressed
-
- 10 Oct, 2006 3 commits
-
-
ted@ted.mysql.internal authored
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
statement. The problem was that during statement re-execution if the result was empty the old result could be returned for group functions. The solution is to implement proper cleanup() method in group functions.
-
- 27 Sep, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Re-execution of a parametrized prepared statement or a stored routine with a SELECT that use LEFT JOIN with second table having only one row could yield incorrect result. The problem appeared only for left joins with second table having only one row (aka const table) and equation conditions in ON or WHERE clauses that depend on the argument passed. Once the condition was false for second const table, a NULL row was created for it, and any field involved got NULL-value flag, which then was never reset. The cause of the problem was that Item_field::null_value could be set without being reset for re-execution. The solution is to reset Item_field::null_value in Item_field::cleanup().
-
- 19 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-
- 16 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
statement that uses an aggregating IN subquery with HAVING clause. A wrong order of the call of split_sum_func2 for the HAVING clause of the subquery and the transformation for the subquery resulted in the creation of a andor structure that could not be restored at an execution of the prepared statement.
-
- 24 Aug, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
Changes in an item tree done by optimizer weren't properly registered and went unnoticed, which resulted in preliminary freeing of used memory.
-
- 23 Aug, 2006 1 commit
-
-
andrey@example.com authored
should work in Prepared Statements. Post-review changeset. Problem: There are some commands which are avaiable to be executed in SP but cannot be prepared. This patch fixes this and makes it possible prepare these statements. Changes: The commands later are made available in PS. RESET has been forbidden in SF/Trigger. Solution: All current server commands where checked and those missing (see later) we added. Tests for all of the commands with repeated executions were added - testing with SP, SF and PS. SHOW BINLOG EVENTS SHOW (MASTER | SLAVE) STATUS SHOW (MASTER | BINARY) LOGS SHOW (PROCEDURE | FUNCTION) CODE (parsable only in debug builds) SHOW CREATE (PROCEDURE | FUNCTION | EVENT | TABLE | VIEW) SHOW (AUTHORS | CONTRIBUTORS | WARNINGS | ERRORS) CHANGE MASTER RESET (MASTER | SLAVE | QUERY CACHE) SLAVE (START | STOP) CHECKSUM (TABLE | TABLES) INSTALL PLUGIN UNINSTALL PLUGIN CACHE INDEX LOAD INDEX INTO CACHE GRANT REVOKE KILL (CREATE | RENAME | DROP) DATABASE (CREATE | RENAME | DROP) USER FLUSH (TABLE | TABLES | TABLES WITH READ LOCK | HOSTS | PRIVILEGES | LOGS | STATUS | MASTER | SLAVE | DES_KEY_FILE | USER_RESOURCES)
-
- 02 Aug, 2006 1 commit
-
-
kostja@bodhi.local authored
-
- 14 Jul, 2006 1 commit
-
-
- 11 Jul, 2006 1 commit
-
-
kostja@bodhi.local authored
when dropping/creating tables"
-
- 06 Jul, 2006 1 commit
-
-
konstantin@bodhi.netgear authored
dropping/creating tables". The bug could lead to a crash when multi-delete statements were prepared and used with temporary tables. The bug was caused by lack of clean-up of multi-delete tables before re-execution of a prepared statement. In a statement like DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is moved to lex->auxilliary_table_list and excluded from lex->query_tables or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use and not cleaned up before re-execution of a prepared statement.
-
- 26 Jun, 2006 1 commit
-
-
konstantin@mysql.com authored
Bug#19022 "Memory bug when switching db during trigger execution" Bug#17199 "Problem when view calls function from another database." Bug#18444 "Fully qualified stored function names don't work correctly in SELECT statements" Documentation note: this patch introduces a change in behaviour of prepared statements. This patch adds a few new invariants with regard to how THD::db should be used. These invariants should be preserved in future: - one should never refer to THD::db by pointer and always make a deep copy (strmake, strdup) - one should never compare two databases by pointer, but use strncmp or my_strncasecmp - TABLE_LIST object table->db should be always initialized in the parser or by creator of the object. For prepared statements it means that if the current database is changed after a statement is prepared, the database that was current at prepare remains active. This also means that you can not prepare a statement that implicitly refers to the current database if the latter is not set. This is not documented, and therefore needs documentation. This is NOT a change in behavior for almost all SQL statements except: - ALTER TABLE t1 RENAME t2 - OPTIMIZE TABLE t1 - ANALYZE TABLE t1 - TRUNCATE TABLE t1 -- until this patch t1 or t2 could be evaluated at the first execution of prepared statement. CURRENT_DATABASE() still works OK and is evaluated at every execution of prepared statement. Note, that in stored routines this is not an issue as the default database is the database of the stored procedure and "use" statement is prohibited in stored routines. This patch makes obsolete the use of check_db_used (it was never used in the old code too) and all other places that check for table->db and assign it from THD::db if it's NULL, except the parser. How this patch was created: THD::{db,db_length} were replaced with a LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were manually checked and: - if the place uses thd->db by pointer, it was fixed to make a deep copy - if a place compared two db pointers, it was fixed to compare them by value (via strcmp/my_strcasecmp, whatever was approproate) Then this intermediate patch was used to write a smaller patch that does the same thing but without a rename. TODO in 5.1: - remove check_db_used - deploy THD::set_db in mysql_change_db See also comments to individual files.
-
- 14 Jun, 2006 1 commit
-
-
bar@mysql.com authored
Problem: cast to unsigned limited result to max signed bigint 9223372036854775808, instead of max unsigned bigint 18446744073709551615. Fix: don't use args[0]->val_int() when casting from a floating point number, use val() instead, with range checkings, special to unsigned data type. item_func.cc: Special handling of cast from REAL_RESULT to unsigned int: we cannot execute args[0]->val_int() because it cuts max allowed value to LONGLONG_INT, instead of ULONGLONG_INT required. count_distinct3.test: Getting rid of "Data truncated; out of range ..." warnings. cast.test, cast.result: Adding test case. ps.result: Fixing that cast from 6570515219.6535 to unsigned didn't round to 6570515220, and returned 6570515219 instead.
-
- 06 Jun, 2006 1 commit
-
-
monty@mysql.com authored
Add define YASSL_PREFIX when compiling yassl Import patch from yaSSL - avoid allocating memory for each call to 'EVP_md5' and 'EVP_des_ede3_cbc' which were not released until server was stopped - Those functions are used from the SQL function 'des_encrypt' and 'des_decrypt'. Add new define YASSL_PREFIX beforee including ssl.h to activate inclusion of prefix_*.h files Bug#20022 mysql-test-run can't be run with secure connections turned on for all testcases - Part 1, fixes rpl- and federated-tests where connection is made to 127.0.0.1 - Include prefix files that renames all public functions in yaSSLs OpenSSL API to ya<function_name>. They will otherwise conflict with OpenSSL functions if loaded by an application that uses OpenSSL as well as libmysqlclient with yaSSL support. Bug#18235: assertion/crash when windows mysqld is ended with ctrl-c Two threads both try a shutdown sequence which creates a race to the de-init/free of certain resources. This exists in similar form in the client as 17926: "mysql.exe crashes when ctrl-c is pressed in windows." Update after merge to 5.0 BUG#18669: Session COM_STATISTICS breaks mysqladmin status. Changed COM_STATISTICS to display the global status, instead of thead status, for slow queries and table opens. - In function 'handle_grant_struct' when searching the memory structures for an entry to modify, convert all entries here host.hostname is NULL to "" and compare that with the host passed in argument "user_from". - A user created with hostname "" is stored in "mysql.user" table as host="" but when loaded into memory it'll be stored as host.hostname NULL. Specifiying "" as hostname means that "any host" can connect. Thus is's correct to turn on allow_all_hosts when such a user is found. - Review and fix other places where host.hostname may be NULL. BUG#19394 OPT_INNODB_THREAD_CONCURRENCY duplicated Removed duplication (not a user-visible change)
-
- 29 May, 2006 1 commit
-
-
msvensson@shellback.(none) authored
-
- 25 Apr, 2006 1 commit
-
-
konstantin@mysql.com authored
supported in SP but not in PS": just enable them in prepared statements, the supporting functionality was implemented when they were enabled in stored procedures.
-
- 12 Apr, 2006 1 commit
-
-
konstantin@mysql.com authored
limit.
-
- 07 Apr, 2006 2 commits
-
-
konstantin@mysql.com authored
too many open statements". The patch adds a new global variable @@max_prepared_stmt_count. This variable limits the total number of prepared statements in the server. The default value of @@max_prepared_stmt_count is 16382. 16382 small statements (a select against 3 tables with GROUP, ORDER and LIMIT) consume 100MB of RAM. Once this limit has been reached, the server will refuse to prepare a new statement and return ER_UNKNOWN_ERROR (unfortunately, we can't add new errors to 4.1 without breaking 5.0). The limit is changeable after startup and can accept any value from 0 to 1 million. In case the new value of the limit is less than the current statement count, no new statements can be added, while the old still can be used. Additionally, the current count of prepared statements is now available through a global read-only variable @@prepared_stmt_count.
-
konstantin@mysql.com authored
gives wrong results". Implement previously missing Item_row::cleanup. The bug is not repeatable in 5.0, probably due to a coincidence: the problem is present in 5.0 as well.
-
- 28 Mar, 2006 1 commit
-
-
pem@mysql.com authored
-
- 27 Feb, 2006 1 commit
-
-
dlenev@mysql.com authored
-
- 23 Feb, 2006 1 commit
-
-
konstantin@mysql.com authored
fixed in 5.0). A post-review fix (Bug#13134)
-
- 21 Feb, 2006 1 commit
-
-
konstantin@mysql.com authored
column is increasing when table is recreated with PS/SP": make use of create_field::char_length more consistent in the code. Reinit create_field::length from create_field::char_length for every execution of a prepared statement (actually fixes the bug).
-
- 01 Feb, 2006 1 commit
-
-
anozdrin@mysql.com authored
Implement table-level TRIGGER privilege to control access to triggers. Before this path global SUPER privilege was used for this purpose, that was the big security problem. In details, before this patch SUPER privilege was required: - for the user at CREATE TRIGGER time to create a new trigger; - for the user at DROP TRIGGER time to drop the existing trigger; - for the definer at trigger activation time to execute the trigger (if the definer loses SUPER privilege, all its triggers become unavailable); This patch changes the behaviour in the following way: - TRIGGER privilege on the subject table for trigger is required: - for the user at CREATE TRIGGER time to create a new trigger; - for the user at DROP TRIGGER time to drop the existing trigger; - for the definer at trigger activation time to execute the trigger (if the definer loses TRIGGER privilege on the subject table, all its triggers on this table become unavailable). - SUPER privilege is still required: - for the user at CREATE TRIGGER time to explicitly set the trigger definer to the user other than CURRENT_USER(). When the server works with database of the previous version (w/o TRIGGER privilege), or if the database is being upgraded from the previous versions, TRIGGER privilege is granted to whose users, who have CREATE privilege.
-
- 16 Jan, 2006 1 commit
-
-
konstantin@mysql.com authored
-
- 14 Jan, 2006 2 commits
-
-
konstantin@mysql.com authored
-
konstantin@mysql.com authored
return incorrect result set for a select SQL request"
-
- 10 Jan, 2006 1 commit
-
-
andrey@lmy004. authored
- fixed test results - fixed bug caught by information_schema.test . Bison temporal variables are very nice but extremely error-prone (Count one more time just to be sure).
-
- 26 Dec, 2005 1 commit
-
-
sergefp@mysql.com authored
-
- 28 Nov, 2005 1 commit
-
-
ramil@mysql.com authored
-
- 25 Nov, 2005 1 commit
-
-
konstantin@mysql.com authored
-