An error occurred fetching the project authors.
- 30 Oct, 2006 1 commit
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
- 27 Oct, 2006 2 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug22584
-
kroki/tomash@moonlight.intranet authored
a updatable view. When there's a VIEW on a base table that have AUTO_INCREMENT column, and this VIEW doesn't provide an access such column, after INSERT to such VIEW LAST_INSERT_ID() did not return the value just generated. This behaviour is intended and correct, because if the VIEW doesn't list some columns then these columns are effectively hidden from the user, and so any side effects of inserting default values to them. However, there was a bug that such statement inserting into a view would reset LAST_INSERT_ID() instead of leaving it unchanged. This patch restores the original value of LAST_INSERT_ID() instead of resetting it to zero.
-
- 25 Oct, 2006 4 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819
-
kroki/tomash@moonlight.intranet authored
If the error happens during DELETE IGNORE, nothing could be send to the client, thus leaving it frozen expecting the reply. The problem was that if some error occurred, it wouldn't be reported to the client because of IGNORE, but neither success would be reported. MySQL 4.1 would not freeze the client, but will report ERROR 1105 (HY000): Unknown error instead, which is also a bug. The solution is to report success if we are in DELETE IGNORE and some non-fatal error has happened.
-
- 24 Oct, 2006 1 commit
-
-
joerg@trift2. authored
-
- 23 Oct, 2006 2 commits
-
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge
-
- 21 Oct, 2006 1 commit
-
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
- 20 Oct, 2006 10 commits
-
-
Raised version number to 5.0.28
-
into mysql.com:/Users/kent/mysql/bk/mysql-5.0
-
Copy udf examples and raid.h Create target "include" directory before copying files to it CMakeLists.txt: Only compile in bdb if configured configure.in: Raised version number to 5.0.27
-
cmiller@zippy.cornsilk.net authored
Revert 1 June change enough to restore ABI compatibility with previous versions.
-
anozdrin/alik@alik. authored
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg15228-2
-
dlenev@mockturtle.local authored
warnings in sql_trigger.cc and sql_view.cc". According to the current version of C++ standard offsetof() macro can't be used for non-POD types. So warnings were emitted when we tried to use this macro for TABLE_LIST and Table_triggers_list classes. Note that despite of these warnings it was probably safe thing to do. This fix tries to circumvent this limitation by implementing custom version of offsetof() macro to be used with these classes. This hack should go away once we will refactor File_parser class. Alternative approaches such as disabling this warning for sql_trigger.cc/sql_view.cc or for the whole server were considered less explicit. Also I was unable to find a way to disable particular warning for particular _part_ of file in GCC.
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt
-
- 19 Oct, 2006 15 commits
-
-
malff/marcsql@weblab.(none) authored
This patch reverts a change introduced by Bug 6951, which incorrectly set thd->abort_on_warning for stored procedures. As per internal discussions about the SQL_MODE=TRADITIONAL, the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE trigger. Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE have been included or revised, to reflect the intended behavior. (reposting approved patch, to work around source control issues, no review needed)
-
svoj@mysql.com/april.(none) authored
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-4.1-engines
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-4.1-engines
-
istruewing@chilla.local authored
Backport from 5.1. Raised STACK_MIN_SIZE for Debian GNU/Linux Sid, Linux kernel 2.6.16, gcc version 3.3.6 (Debian 1:3.3.6-13), libc6-dbg 2.3.6.ds1-4, Pentium4 (x86), BUILD/compile-pentium-debug-max Raised about 100 Bytes above the required minimum.
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21856
-
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.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-merge
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-merge
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-merge
-
igor@rurik.mysql.com authored
-
- 18 Oct, 2006 3 commits
-
-
into mysql.com:/data0/bk/mysql-5.0-kt
-
svoj@mysql.com/april.(none) authored
Repair table could crash a server if there is not sufficient memory (myisam_sort_buffer_size) to operate. Affects not only repair, but also all statements that use create index by sort: repair by sort, parallel repair, bulk insert. Return an error if there is not sufficient memory to store at least one key per BUFFPEK. Also fixed memory leak if thr_find_all_keys returns an error.
-
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 1 commit
-
-
evgen@sunlight.local authored
into sunlight.local:/local_work/14959-bug-5.0-opt-mysql
-