- 18 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
(COUNT(*) = 1) not working in SELECT inside prepared statement. Note: the warning was introduced in 5.0 and 5.1, 4.1 is OK with the original fix. The problem was that in 5.0 and 5.1 clear() for group functions may access hybrid_type member, and this member is initialized in fix_fields(). So we should not call clear() from item cleanup() methods, as cleanup() may be called for unfixed items.
-
- 17 Oct, 2006 2 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21726
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21726
-
- 12 Oct, 2006 3 commits
-
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug20953
-
kroki/tomash@moonlight.intranet authored
should fail to create The problem was that this type of errors was checked during view creation, which doesn't happen when CREATE VIEW is a statement of a created stored routine. The solution is to perform the checks at parse time. The idea of the fix is that the parser checks if a construction just parsed is allowed in current circumstances by testing certain flags, and this flags are reset for VIEWs. The side effect of this change is that if the user already have such bogus routines, it will now get a error when trying to do SHOW CREATE PROCEDURE proc; (and some other) and when trying to execute such routine he will get ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6) However there should be very few such users (if any), and they may (and should) drop these bogus routines.
-
- 10 Oct, 2006 10 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug19111
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354
-
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.
-
petr/cps@mysql.com/owlet.local authored
into mysql.com:/home/cps/mysql/trees/mysql-5.0-virgin
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug19111
-
kroki/tomash@moonlight.intranet authored
In a trigger or a function used in a statement it is possible to do SELECT from a table being modified by the statement. However, encapsulation of such SELECT into a view and selecting from a view instead of direct SELECT was not possible. This happened because tables used by views (which in their turn were used from functions/triggers) were not excluded from checks in unique_table() routine as it happens for the rest of tables added to the statement table list for prelocking. With this fix we ignore all such tables in unique_table(), thus providing consistency: inside a trigger or a functions SELECT from a view may be used where plain SELECT is allowed. Modification of the same table from function or trigger is still disallowed. Also, this patch doesn't affect the case where SELECT from the table being modified is done outside of function of trigger, such SELECTs are still disallowed (this limitation and visibility problem when function select from a table being modified are subjects of bug 21326). See also bug 22427.
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
- 09 Oct, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
The syntax of the CALL statement, to invoke a stored procedure, has been changed to make the use of parenthesis optional in the argument list. With this change, "CALL p;" is equivalent to "CALL p();". While the SQL spec does not explicitely mandate this syntax, supporting it is needed for practical reasons, for integration with JDBC / ODBC connectors. Also, warnings in the sql/sql_yacc.yy file, which were not reported by Bison 2.1 but are now reported by Bison 2.2, have been fixed. The warning found were: bison -y -p MYSQL -d --debug --verbose sql_yacc.yy sql_yacc.yy:653.9-18: warning: symbol UNLOCK_SYM redeclared sql_yacc.yy:656.9-17: warning: symbol UNTIL_SYM redeclared sql_yacc.yy:658.9-18: warning: symbol UPDATE_SYM redeclared sql_yacc.yy:5169.11-5174.11: warning: unused value: $2 sql_yacc.yy:5208.11-5220.11: warning: unused value: $5 sql_yacc.yy:5221.11-5234.11: warning: unused value: $5 conflicts: 249 shift/reduce "unused value: $2" correspond to the $$=$1 assignment in the 1st {} block in table_ref -> join_table {} {}, which does not procude a result ($$) for the rule but an intermediate $2 value for the action instead. "unused value: $5" are similar, with $$ assignments in {} actions blocks which are not for the final reduce.
-
- 08 Oct, 2006 3 commits
-
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/bk/mysql-5.0-engines
-
- 06 Oct, 2006 9 commits
-
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG22937/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG22937/mysql-4.1-engines
-
svoj@mysql.com/april.(none) authored
This is addition to fix for bug21617. Valgrind reports an error when opening merge table that has underlying tables with less indexes than in a merge table itself. Copy at most min(file->keys, table->key_parts) elements from rec_per_key array. This fixes problems when merge table and subtables have different number of keys.
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
-
kroki/tomash@moonlight.intranet authored
Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored procedures. However, 4.1 had some bugs that were fixed in 5.0 by the patch for bug#21726, and this patch is a backport of those fixes. Namely, in 4.1 it fixes: - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific). - LAST_INSERT_ID() could return the value generated by current statement if the call happens after the generation, like in CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT); INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID()); - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
-
svoj@mysql.com/april.(none) authored
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG10974/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
-
- 05 Oct, 2006 5 commits
-
-
petr/cps@mysql.com/owlet.local authored
Stop guardian and all the rest of threads before shutdown in case of an error
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-4.1-engines
-
svoj@mysql.com/april.(none) authored
Though this is not storage engine specific problem, I was able to repeat this problem with BDB and NDB engines only. That was the reason to add a test case into ndb_update.test. As a result different bad things could happen. BDB has removed duplicate rows which is not expected. NDB returns an error. For multi table update notify storage engine about UPDATE IGNORE as it is done in single table UPDATE.
-
gluh@mysql.com/gluh.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-kt
-
- 04 Oct, 2006 1 commit
-
-
petr/cps@mysql.com/owlet.local authored
the option is useless on windows. It was removed from listing of mysqlmanager --help on Windows
-
- 03 Oct, 2006 5 commits
-
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
-
anozdrin/alik@alik. authored
The problem was a race condition in a test case. The fix eliminates the race condition by explicit wait on UNIX socket to start accepting connections. The patch affects only test suite (i.e. does not touch server codebase).
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726-fix
-
anozdrin/alik@booka. authored
into booka.:/home/alik/MySQL/devel/5.0-rt
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726-fix
-