- 29 Nov, 2006 20 commits
-
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.0-opt
-
evgen@moonbone.local authored
Small fix for a test case
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-4.1-opt
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/mysql-5.0-build
-
evgen@moonbone.local authored
into moonbone.local:/work/20327-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
prepared statement and subquery. When a field of a view from an outer select is resolved the find_field_in_view function creates an Item_direct_view_ref object that references the corresponding view underlying field. After that the view_ref is marked as a dependent one. While resolving view underlying field it also get marked as a dependent one due to current_select still points to the subselect. Marking the view underlying field is wrong and lead to attaching conditions to a wrong table and thus to the wrong result of the whole statement. Now mark_select_range_as_dependent() function isn't called for fields from a view underlying table.
-
evgen@moonbone.local authored
into moonbone.local:/work/17254-bug-5.0-opt-mysql
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-4.1-opt
-
df@kahlann.erinye.com authored
into kahlann.erinye.com:/home/df/mysql/build/mysql-4.1-build-work
-
df@kahlann.erinye.com authored
into kahlann.erinye.com:/home/df/mysql/build/mysql-5.0-build-work
-
df@kahlann.erinye.com authored
into kahlann.erinye.com:/home/df/mysql/build/mysql-5.0-build-work
-
df@kahlann.erinye.com authored
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/thfix/my50-thfix
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/thfix/my50-thfix
-
holyfoot/hf@mysql.com/deer.(none) authored
the problem is that client tools are compiled with UNDEF_THREADS_HACK flag, and my thread-related additions to the mysqltest.c can't be compiled. Easy solution is to disable these in not-embedded case completely.
-
- 28 Nov, 2006 12 commits
-
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
joerg@trift2. authored
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/mysql-5.0-build
-
kent@mysql.com/kent-amd64.(none) authored
Handle the case "sql_yacc.cc" is pregenerated or not, and that the case where the source and build tree is the same or not.
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/mysql-5.0-build
-
kent@mysql.com/kent-amd64.(none) authored
If using \$(srcdir)/mysql.info in action, use same in rule.
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B24156-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
statements Currently the optimizer evaluates loose index scan only for top-level SELECT statements Extend loose index scan applicability by : - Test the applicability of loose scan for each sub-select, instead of the whole query. This change enables loose index scan for sub-queries. - allow non-select statements with SELECT parts (like, e.g. CREATE TABLE .. SELECT ...) to use loose index scan.
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B11927-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
When implicitly converting string fields to numbers the string-to-number conversion error was not sent to the client. Added code to send the conversion error as warning. We also need to prevent generation of warnings from the places where val_xxx() methods are called for the sole purpose of updating the Item::null_value flag. To achieve that a special function is added (and called) : update_null_value(). This function will set the no_errors flag and will call val_xxx(). The warning generation in Field_string::val_xxx() will use the flag when generating the conversion warnings.
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
- 27 Nov, 2006 8 commits
-
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/mysql-5.0-build
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/mysql-5.0-merge
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/mysql-4.1-merge
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/mysql-5.0
-
kent@mysql.com/kent-amd64.(none) authored
Reenabled build outside source tree
-
into mysql.com:/Users/kent/mysql/bk/build/mysql-5.0-build
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/mysql-5.0
-
kent@mysql.com/kent-amd64.(none) authored
BSD compatibility
-