- 30 Jan, 2007 2 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug24987
-
igor@olga.mysql.com authored
Made the function opt_sum_query to return HA_ERR_KEY_NOT_FOUND when no matches were found (instead of -1 it returned prior this patch). This changes allow us to avoid possible conflicts with return values from user-defined handler methods which also may return -1. No particular test cases are provided with this fix.
-
- 27 Jan, 2007 1 commit
-
-
igor@olga.mysql.com authored
Objects of the classes Item_func_is_not_null_test and Item_func_trig_cond must be transparent for the method Item::split_sum_func2 as these classes are pure helpers. It means that the method Item::split_sum_func2 should look at those objects as at pure wrappers.
-
- 26 Jan, 2007 5 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug24653
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug24653
-
igor@olga.mysql.com authored
The bug report has demonstrated the following two problems. 1. If an ORDER/GROUP BY list includes a constant expression being optimized away and, at the same time, containing single-row subselects that return more that one row, no error is reported. Strictly speaking the standard allows to ignore error in this case. Yet, now a corresponding fatal error is reported in this case. 2. If a query requires sorting by expressions containing single-row subselects that, however, return more than one row, then the execution of the query may cause a server crash. To fix this some code has been added that blocks execution of a subselect item in case of a fatal error in the method Item_subselect::exec.
-
- 25 Jan, 2007 1 commit
-
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-merge
-
- 24 Jan, 2007 22 commits
-
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-bug8804-r12
-
sergefp@mysql.com authored
Fixed typo problem that surfaced after the merge
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
-
sergefp@mysql.com authored
identical pushed_cond_guards arrays. Allocate only one always.
-
dlenev@mockturtle.local authored
the team tree for additional investigation.
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-merge
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-bug8804-r12
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug24607
-
istruewing@chilla.local authored
After merge fix
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug24607
-
istruewing@chilla.local authored
Fixed test. On 32-bit machines which compile without -DBIG_TABLES, MAX_ROWS is truncated to a 32-bit value. Using a value below 4G is portable.
-
df@kahlann.erinye.com authored
into kahlann.erinye.com:/home/df/mysql/build/mysql-5.0-build-work
-
svoj@mysql.com/june.mysql.com authored
-
svoj@mysql.com/june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG24401/mysql-5.0-engines
-
svoj@mysql.com/june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG24401/mysql-5.0-engines
-
svoj@mysql.com/june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG24401/mysql-4.1-engines
-
stewart@willster.(none) authored
into willster.(none):/home/stewart/Documents/MySQL/5.0/ndb-work
-
stewart@willster.(none) authored
-
tomas@poseidon.mysql.com authored
into poseidon.mysql.com:/home/tomas/mysql-5.0-ndb
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
- 23 Jan, 2007 9 commits
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug24607
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug24607
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
pekka@clam.ndb.mysql.com/clam.(none) authored
into clam.ndb.mysql.com:/export/space/pekka/ndb/version/my50-ndb
-
stewart@willster.(none) authored
into willster.(none):/home/stewart/Documents/MySQL/5.0/bug25487
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg24491
-
svoj@mysql.com/june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG24401/mysql-5.0-engines
-
dlenev@mockturtle.local authored
on duplicate key". INSERT ... SELECT ... ON DUPLICATE KEY UPDATE which was used in stored routine or as prepared statement and which in its ON DUPLICATE KEY clause erroneously tried to assign value to a column mentioned only in its SELECT part was properly emitting error on the first execution but succeeded on the second and following executions. Code which is responsible for name resolution of fields mentioned in UPDATE clause (e.g. see select_insert::prepare()) modifies table list and Name_resolution_context used in this process. It uses Name_resolution_context_state::save_state/restore_state() to revert these modifications. Unfortunately those two methods failed to revert properly modifications to TABLE_LIST::next_name_resolution_table and this broke name resolution process for successive executions. This patch fixes Name_resolution_context_state::save_state/restore_state() in such way that it properly handles TABLE_LIST::next_name_resolution_table.
-