- 28 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
-
- 26 Mar, 2007 5 commits
-
-
gkodinov/kgeorge@magare.gmz authored
enabled the optional FOR JOIN to all the three clauses : USE, FORCE and IGNORE
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/B27164-5.0-opt
-
gkodinov/kgeorge@magare.gmz[kgeorge] authored
to 0 causes wrong (large) length to be read from the row in _mi_calc_blob_length() when storing NULL values in (e.g) POINT columns. This large length is then used to allocate a block of memory that (on some OSes) causes trouble. Fixed by calling the base class's Field_blob::reset() from Field_geom::reset() that is called when storing a NULL value into the column.
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug27229
-
igor@olga.mysql.com authored
from func_group.test after the patch for bug #27229 had been applied. The memory corruption happened because in some rare cases the function count_field_types underestimated the number of elements in in the array param->items_to_copy.
-
- 23 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B26186-5.0-opt
-
- 22 Mar, 2007 32 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug27229
-
igor@olga.mysql.com authored
context was used as an argument of GROUP_CONCAT. Ensured correct setting of the depended_from field in references generated for set functions aggregated in outer selects. A wrong value of this field resulted in wrong maps returned by used_tables() for these references. Made sure that a temporary table field is added for any set function aggregated in outer context when creation of a temporary table is needed to execute the inner subquery.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/26813-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
Post-fix for bug#26813.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-4.1-opt
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/26813-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
another user. When the DEFINER clause isn't specified in the ALTER statement then it's loaded from the view definition. If the definer differs from the current user then the error is thrown because only a super-user can set other users as a definers. Now if the DEFINER clause is omitted in the ALTER VIEW statement then the definer from the original view is used without check.
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B26186-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B26207-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
in index search MySQL was not explicitly suppressing warnings. And if the context happens to enable warnings (e.g. INSERT .. SELECT) the warnings resulting from converting the data the key is compared to are reported to the client. Fixed by suppressing warnings when converting the data to the same type as the key parts.
-
mhansson/martin@linux-st28.site authored
Patch appled after doing a pull from the team tree. Additional tests had to be fixed
-
mhansson/martin@linux-st28.site authored
into linux-st28.site:/home/martin/mysql/src/5.0o-bug24791
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb
-
jonas@perch.ndb.mysql.com authored
fix test prg
-
mhansson/martin@linux-st28.site authored
into linux-st28.site:/home/martin/mysql/src/5.0o-bug24791
-
mhansson/martin@linux-st28.site authored
The problem in this bug is when we create temporary tables. When temporary tables are created for unions, there is some inferrence being carried out regarding the type of the column. Whenever this column type is inferred to be REAL (i.e. FLOAT or DOUBLE), MySQL will always try to maintain exact precision, and if that is not possible (there are hardware limits, since FLOAT and DOUBLE are stored as approximate values) will switch to using approximate values. The problem here is that at this point the information about number of significant digits is not available. Furthermore, the number of significant digits should be increased for the AVG function, however, this was not properly handled. There are 4 parts to the problem: #1: DOUBLE and FLOAT fields don't display their proper display lengths in max_display_length(). This is hard-coded as 53 for DOUBLE and 24 for FLOAT. Now changed to instead return the field_length. #2: Type holders for temporary tables do not preserve the max_length of the Item's from which they are created, and is instead reverted to the 53 and 24 from above. This causes *all* fields to get non-fixed significant digits. #3: AVG function does not update max_length (display length) when updating number of decimals. #4: The function that switches to non-fixed number of significant digits should use DBL_DIG + 2 or FLT_DIG + 2 as cut-off values (Since fixed precision does not use the 'e' notation) Of these points, #1 is the controversial one, but this change is preferred and has been cleared with Monty. The function causes quite a few unit tests to blow up and they had to b changed, but each one is annotated and motivated. We frequently see the magical 53 and 24 give way to more relevant numbers.
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
-
holyfoot/hf@mysql.com/hfmain.(none) authored
fix for cast( AS DATETIME)+0 in 5.0 and above versions. val_real now works using val_decimal for DATETIME Items Superfluous val_real() methods deleted
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
fix for cast( AS DATETIME) + 0 operation. I just implemented Item_datetime_typecast::val() method as it is usually done in other classes. Should be fixed more radically in 5.0
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-4.1-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/25492/my50-25492
-
igor@olga.mysql.com authored
of its argument happened to be a decimal expression returning the NULL value. The crash was due to the fact the function in_decimal::set did not take into account that val_decimal() could return 0 if the decimal expression had been evaluated to NULL.
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
-
- 21 Mar, 2007 1 commit
-
-
tsmith@quadxeon.mysql.com authored
into quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/50
-